はじめに こんにちは。普段は@niftyトップページの開発運用をしている宮本です。 最近 git worktree で並行して開発していたところ、 .terraform や node_modules フォルダが大量に作成され、気づいたらPCのストレージが限界に近づいていました。便利で多用していたのですが、掃除をしないと思わぬ落とし穴がありますね。 さて、今回の記事では自分が開発運用担当している一部のサイトで利用しているAmplifyについて、1年以上運用してみた感想について紹介させていただきます。 AWS Amplify AWS Amplify （以下Amplify）はフロントからバックエンドまでを一括で管理できるマネージドサービスです。 サイト運用に必要なAWSリソースを裏側で準備してくれるだけでなく、Gitリポジトリと連携することでブランチごとのサイトの状態を確認できたりすることが大きな特徴です。 前提 この記事ではAmplifyを利用してサイトを1年以上運用してきた経験を元に記述していますが、以下のようなサイトを運用しています。 Astro製SSGのWebサイトの運用がメイン Next.jsを用いたSSRは一部サイトのみ利用 CognitoやDynamoDBなどの各種AWSリソースの利用は無し GitHub連携を利用 AWS Amplify CLIは未利用 特にAmplifyを利用する際に大きな利点となりそうな他のAWSリソースとの組み合わせは試したことがないため、これについては触れません。 便利だった点 手軽にサイトを立てることができる PRごとに自動でサイトを作ることができる ブランチごとに環境変数を設定することができる Basic認証が機能として用意されている 手軽にサイトを立てることができる Amplifyを作成してビルド設定のファイルを用意してリポジトリと接続するだけでサイトを作れるため、特にSSRを用いるサイトだとコンテナ周りの煩雑な準備をせずに済むのが楽でした。 一方で、以下のような条件が重なった場合は必ずしも最も手軽とは言い切れないようにも感じました。 単純なs3+CloudFrontのみで事足りるようなSSGサイト AWS CDKなどのIaCツールを利用して運用することを前提にしている 特に単純な静的サイト用のIaCコードは簡単にAI生成できるため、リソースの準備は比較的容易です。リソースに加えてサイトのビルド+アップロードの構築もありますが、これもGitHub Actionsを用いることで比較的簡単に準備できると感じました。 PRごとに自動でサイトを作ることができる Amplifyを使っていて特に便利だった機能です。 コード変更をしてPRを提出した際、PRごとに専用に新しく割り振られたドメインでサイトの確認が可能になります。 マージ前に変更内容を確認するために、ローカルでブランチを切り替えずとも確認できるサイトが自動でデプロイされるのはとてもありがたかったです。 この辺りを自力で作ろうとするのはかなり大変なので、明確にAmplifyの利点だと感じました。 ブランチごとに環境変数を設定することができる 本番・ステージング・開発環境と複数の環境を常に用意していると、環境によってサイト自体の動作を変更したいケースがあります。 担当しているサイトではCMSを用いて運用していたため、一部の環境では本番公開前のデータを取得し、また開発環境では開発環境のCMSからデータを取得したいということがありました。 このときAmplifyアプリそのものを分けずともブランチごとの設定で分けられるのは便利でした。 Basic認証が機能として用意されている 本番環境以外を一般公開しないようにするため、デフォルトでBasic認証を仕掛けることができるのは便利でした。 デフォルトで組み込まれていない場合はWAFを設定したり、前段にCloudFrontを用意した上でCloudFront Functionsで制御する等々が必要になり、またブランチやPRごとに自動で作成されるサイトには追加することができないため一気に扱い辛くなっていたと思います。 詰まった点・もう少し便利だと嬉しい点 リダイレクトでワイルドカードを利用できる箇所が限られる IaC管理しようとするとやや複雑 ビルド通知を使いやすくしようとするとやや手間がかかる ビルド時のログを出力できない Git上のブランチに必ず依存する IaC管理しようとするとやや複雑 基本的にリソースは全てIaCで管理するようにしているのですが、Amplify自体の管理がやや複雑でした。TerraformとAWS CDKどちらも利用して作成したことがありますが、Amplify管理についてはこの二つの差はあまり感じませんでした。 IaCで管理しようとした場合、Amplify本体のリソースとブランチごとの環境を定義する必要があり少々記述量が多くなります。また、GitHubリポジトリとの接続でリソース作成時はPAT認証が必要になるなど、引っかかる点もありました。 この辺り、簡単にリソースを作成して煩わしさを省くためのAmplifyなので、厳格さを求めるIaCとは若干相性が悪いようにも感じました。 ビルド通知を使いやすくしようとすると手間がかかる Amplifyのビルド通知は、デフォルトではemailのみ対応しています。効率を考えるとslack等に流したいですが、機能としては存在しません。 ビルド自体はEventBridgeをトリガーに検知することができるため、そこからLambdaなどを使うことで通知することはできます。興味がある方は 以前書いた記事 をご参照ください。 ただ、そもそも必要なリソースを設定一つで用意できるのがAmplifyの利点にもかかわらず、別途細かい仕様を把握しリソースを作る必要があるという点が少々煩わしく感じました。 ビルド時のログをCloudWatchに出力できない Amplifyは連携されたコードを元に、Amplify上でコードをビルドしたものをサイトとして公開します。ここで厄介なのが、ビルド時のログそのものはAmplifyのコンソール画面でしか確認できない点です。 SSRでアクセス時に出力されるアプリケーションログはCloudWatch Logsに出力することができますが、ビルド時のログはCloudWatch Logsには出力されません。 よってSSGのサイトなどでビルド時にデータ取得に失敗した場合なども、どこで異常が発生したのかコンソールからたどる必要がある点が運用を考えると少々手間です。 もっとも、これについてはGitHub actionsなどでビルドする場合も同じかもしれません。普段AWSを使っているとCloudWatch Logsからアラートを流しているからこそ、少々物足りなく感じた部分もありました。 Git上のブランチに必ず依存する AmplifyのデプロイはGit上のブランチに紐づいていて便利ですが、このブランチがなくなると環境が消えてしまいます。 本番稼働ブランチなど設定することはできますが、特に保護されているわけでもなく依存しているブランチが消えた場合は該当のブランチの環境は容赦無く削除されます。 よって、本番で動作しているブランチについては確実にGitHubのブランチ保護のルールを仕掛けましょう。初歩的すぎてAmplifyを使わずとも注意すべき当たり前のことではありますが、Amplifyの場合はブランチの誤削除がダイレクトにサイトそのものの存在と直結します。そのためリスクは普段以上に大きく注意が必要です。 特に多くのサイトを管理している場合、うっかり一つでも保護漏れがないか注意しましょう。 まとめ 正直なところAmplifyの機能のさわり程度しかまだ利用していませんが、さわり程度でもPRプレビュー機能などかなり便利に感じる箇所は多いです。ECSで動作させているサイトでPRごとに環境を用意しようとした場合、環境の準備はもちろんデプロイトリガーの用意など考えることは多く、これを設定のチェック一つで実現してしまう点は非常に強力に感じました。 一方で物足りなく感じる点もあり、ビルドログやビルド通知などAmplify内で多くのことを自動的に処理してしまっているからこそ、そこをカスタマイズしようとすると思った以上に手間がかかったり、そもそも対応できないケースなどが出てきます。 この辺りは単にサイトをデプロイするだけでなく運用も踏まえて考えないと後から躓くポイントになりかねないので、少々厄介なポイントだと思います。 とはいえAmplify自体の機能アップデートも続いており、例えば以前はAmplifyにWAFを直接紐づけられなかったのですが、これも2025年にはGAされています。今後も不便に感じていたポイントがアップデートで解消される可能性もあるので、機能アップデートには注視していきたいです。 参考 https://aws.amazon.com/jp/amplify/

介護ソフトのテストを任されたものの、「一般的な業務システムと同じ観点で確認してよいのだろうか」と迷うケースは少なくありません。 介護ソフトには利用者情報の管理だけでなく、アセスメント、ケアプラン、介護記録、サービス実績、各種帳票、介護報酬請求など、介護現場のさまざまな業務が集約されています。 そのため、個々の画面が仕様通りに動いていることだけを確認しても、十分なテストとはいえません。 たとえば、介護記録への入力自体は正常でも、その情報がサービス実績や帳票、請求処理へ正しく反映されなければ、現場では重大な問題につながります。 さらに介護分野では、介護報酬改定によって算定基準や通知などが変更されたり、LIFE（科学的介護情報システム）のCSV連携仕様が更新されたりするため、外部制度の変更にも継続して対応する必要があります。 2026年7月には介護情報基盤との連携に関するインタフェース仕様書第2.1版も公開されており、介護ソフトの品質保証では自社システムの画面だけでなく、外部システムとのデータの流れまで見る重要性が高まっています。 そこで今回は、 介護業界のソフトウェアテストで押さえたい考え方と具体的なテスト観点を、業務・制度・データ連携の流れで整理しました！ 介護業務を詳しく知らない状態からでも、重大な不具合につながるポイントを見つけやすくするための基本を確認していきます。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 まずここを押さえよう！介護ソフトのテストが一般的な業務システムと違う理由 介護ソフトのテストで重要なのは、 機能そのものではなく、その機能が介護業務全体の中でどのような役割を持っているか を理解することです。 一般的なWebサービスであれば、入力、検索、更新、削除などの機能単位でテスト項目を整理しやすいケースがあります。 一方、介護ソフトでは利用者情報や介護記録が別の画面や帳票へ連携し、最終的にはサービス実績や介護報酬請求へ影響することがあります。 前工程で発生した小さなデータ不整合が、複数の処理を経たあとに請求金額の誤りとして表面化する可能性もあります。 また、介護サービスには制度上の算定条件や適用期間などが存在するため、「システムとして正しく動いているか」だけでなく、 制度上のルールに照らして正しい結果になっているか も確認しなければなりません。 すべての機能を同じ深さでテストするのではなく、請求、個人情報、介護記録、外部提出データなど、問題が発生した際の影響が大きい領域から優先順位を付ける考え方も大切です。 画面が動くだけでは不十分！介護業務の「つながり」からテストしよう 介護ソフトでは、一つの画面だけを見て正常かどうかを判断すると、機能間で発生する不具合を見逃しやすくなります。 利用者を登録したあと、アセスメントを実施し、ケアプランやサービス予定を作成し、実際のサービス提供内容を記録して実績を確定し、その情報を帳票や請求へ使用するというように、業務は連続しています。 したがって、テストケースを設計するときは、 入力した情報が次にどこへ渡り、最終的に何へ使われるのか を追いかけることが重要です。 たとえば利用者の認定情報を変更した場合、その変更が対象画面だけでなく、予定、実績、帳票、請求処理へ正しく反映されるかまで確認します。 各画面の単体テストでは問題がなくても、データを受け渡す際の変換処理や更新処理に不具合が潜んでいる場合があります。 そのため、単体テストや結合テストに加えて、 実際の介護業務を最初から最後まで再現するシナリオテスト を取り入れると、実運用で発生する不整合を発見しやすくなります。 制度を知らないままテストしない！仕様の根拠を先に確認しよう 介護ソフトの仕様には、介護報酬、各種加算、サービスコード、適用期間、帳票など、介護制度に基づいて設計されている部分が数多くあります。 そのため、画面仕様書だけを見ながら期待結果を作ってしまうと、「仕様書通りではあるものの制度上は誤っている」という問題を見逃す可能性があります。 テスト設計では、 その仕様が何を根拠に決められているのか を確認することが大切です。 介護報酬改定では算定基準や関連通知などが変更されるため、変更内容が要件やシステム仕様へ正しく落とし込まれているかも確認する必要があります。 制度知識に不安がある場合は、QA担当者だけで正常・異常を判断せず、介護業務に詳しい担当者やプロダクト担当者と期待結果を共有します。 また、テスト開始後に仕様の曖昧さへ気付くのではなく、要件定義書や設計書を事前にレビューし、矛盾や条件漏れを見つけることも品質保証の重要な工程です。 テストとは完成したプログラムだけを確認する作業ではなく、仕様そのものが正しいかを確かめる活動でもある と考えると、重大な不具合を早い段階で防ぎやすくなります。 全項目を均等に確認しない！重大事故につながる機能から優先しよう 介護ソフトには多くの機能があり、サービス種別や利用者条件、加算などを掛け合わせると、テストパターンは急激に増えていきます。 すべての組み合わせを同じ深さで確認しようとすると、テスト工数が膨らむ一方で、本当に重要な部分へ十分な時間を使えなくなる可能性があります。 そこで有効なのが、 不具合が発生したときの影響度からテストの優先順位を決める考え方 です。 たとえば請求金額が誤る、必要な介護記録が失われる、別の利用者の個人情報が表示される、外部へ誤ったデータを送信するといった問題は、業務や事業所の運営へ大きな影響を与える可能性があります。 一方、表示上の軽微なずれなどは、同じ不具合であっても優先度が異なります。 「どこにバグがありそうか」だけでなく、 「そこでバグが起きたら何が起こるか」から逆算してテスト対象を選ぶ ことが重要です。 請求、利用者情報、介護記録、権限、帳票、外部連携などを重点領域として整理し、リリース前に必ず確認する範囲をあらかじめ決めておくと、限られた期間でも品質を守りやすくなります。 重大な不具合を防ぐ！介護ソフトで重点的に確認したいテスト観点 介護ソフトのテストでは、一般的な入力チェックや画面遷移に加えて、介護業務ならではの観点をテストケースへ落とし込む必要があります。 中心になるのは、利用者情報、介護記録、ケアプラン、サービス予定・実績、介護報酬請求、帳票、権限管理、外部システムとのデータ連携です。 重要なのは、それぞれを独立した機能として確認するだけではありません。 一つのデータが複数の機能へどのように流れるかを確認すること が、介護ソフトの品質を高めるポイントになります。 また、正常なデータを入力して期待通りの結果になることだけでは、実際の現場で起きる問題を十分に再現できません。 日付の境界、入力漏れ、予定変更、修正、重複操作、通信断、複数職員による同時操作などもテストへ組み込みます。 介護現場では毎日継続してシステムが使われるため、単に機能が動くかだけでなく、 実際の運用の中で安全に使い続けられるか まで確認することが大切です。 利用者情報・介護記録・ケアプランは「登録できる」だけで終わらせない！ 利用者情報では、氏名や生年月日の登録だけでなく、認定情報、負担割合、サービス利用期間など、後続処理へ影響する項目を重点的に確認します。 必須項目が空欄の場合、入力可能な最大文字数を超えた場合、過去の日付や想定外の値を入力した場合など、正常系以外のケースも必要です。 特に重要なのが、 登録後に情報を変更した場合の影響 です。 たとえば認定情報を変更したとき、利用者画面だけが更新されても、ケアプランや実績、帳票、請求処理に古い情報が残っていれば、業務上の不整合が発生します。 介護記録についても、登録できることだけでなく、修正や削除を行った場合の履歴、関連帳票への反映、集計結果への影響を確認します。 複数の職員が同じ利用者情報を同時に開いた場合には、後から保存した内容で意図せず上書きされないかも確認が必要です。 また、利用者を取り違えて記録を登録することは重大な問題につながるため、 別利用者への誤登録を防ぎやすい画面・操作になっているか という使いやすさの観点も含めて評価します。 予定・実績・介護報酬請求は最重要！金額まで一連の流れを確認しよう 介護ソフトの中でも特に慎重にテストしたいのが、サービス予定から実績、介護報酬請求へつながる領域です。 サービスを予定通り提供したケースだけでなく、キャンセル、時間変更、回数変更、月途中での状態変更など、現場で発生しやすいパターンを用意します。 そのうえで、実績へ正しく反映され、対象となるサービスや加算が適切に判定され、最終的な請求データまで正しく作成されるかを確認します。 加算については、算定条件をすべて満たすケースだけでは不十分です。 条件を満たすケース、条件を一部だけ満たすケース、条件を満たさないケース を分けて確認すると、誤算定を発見しやすくなります。 単位数や利用者負担などの計算結果についても、画面表示が正しいだけで判断せず、最終的に生成される請求データと一致していることまで追跡します。 介護報酬は2026年度にも改定が行われ、算定基準や関連通知が変更されています。 そのため請求機能では、通常時の正しさに加えて、 制度変更後も旧条件が誤って残っていないか という回帰テストも欠かせません。 境界値と日付条件を狙おう！介護制度ならではの異常系を洗い出す システムの不具合は、通常の利用パターンよりも「条件が切り替わる瞬間」で発生しやすい傾向があります。 介護ソフトでは特に、月末と月初、年度の切り替え、制度改定日、認定期間の開始日と終了日、加算の適用開始日と終了日など、 日付の境界を意識したテスト が重要です。 たとえば4月1日から新しいルールを適用する場合、3月31日、4月1日、4月2日でそれぞれ正しい処理になるかを確認します。 回数や数量についても、0回、1回、上限値、上限を1回超えた値など、条件が変化する前後をテストします。 入力データについては、空欄、不正な文字、桁数超過、重複、存在しないコードなどを使い、異常なデータをシステムが適切に扱えるか確認します。 さらに介護業務では、すでに確定した過去月の記録や実績を修正するケースも考えられます。 その場合は、変更後の情報だけでなく、 修正によって関連する帳票や請求結果がどこまで変わるのか まで確認しておく必要があります。 帳票・権限・個人情報も忘れない！現場運用まで含めて確認しよう 介護ソフトでは入力した情報をさまざまな帳票へ出力するため、画面上の値と帳票の内容が一致しているかも重要なテストポイントです。 項目の欠落、途中で切れる文字、古い情報の表示、ページ分割によるレイアウト崩れなど、データ内容と出力形式の両方を確認します。 特に情報を修正した場合は、変更内容が対象となるすべての帳票へ反映されているかを確認することが大切です。 また、介護ソフトでは利用者の個人情報を扱うため、 職員ごとの権限管理 も重点的にテストする必要があります。 職種や役割によって、閲覧、登録、編集、削除、承認などの操作範囲が正しく制限されているかを確認します。 退職や異動によって権限を変更したあとも、以前の権限で操作できないことを確認しておくと安心です。 さらに、誰がいつどの情報を変更したのかを追跡できる操作履歴や変更履歴も、トラブル発生時の調査に役立ちます。 別利用者の情報が表示される、権限のない職員が閲覧できる、誤った帳票を出力できる といった問題は高リスクとして扱い、優先的に確認します。 スマホ・タブレット・通信断まで再現！「介護現場で使えるか」を確かめよう 介護記録などを現場で入力するシステムでは、パソコンだけでテストを完了させないことも重要です。 実際に利用されるスマートフォンやタブレットを用意し、画面サイズの違いやタッチ操作を含めて確認します。 ボタンが小さすぎないか、入力項目が多すぎないか、必要な情報へすぐ移動できるかなど、 忙しい介護現場でも迷わず操作できるか という視点が欠かせません。 機能として正しく動いていても、一件の記録に多くの操作が必要であれば、現場の負担を増やす可能性があります。 さらに、施設内すべての場所で安定した通信環境が利用できるとは限りません。 通信速度が低下した場合、一時的に接続が切れた場合、通信が復旧した場合を再現し、入力内容が失われないか確認します。 オフライン対応や同期機能がある場合は、復旧後に同じデータが二重登録されたり、古い情報で新しいデータが上書きされたりしないかもテストします。 「仕様通り動くか」と「実際の介護現場で無理なく使えるか」は別の品質 として評価することが大切です。 制度改定・外部連携に強くなろう！変更に振り回されないテスト設計の進め方 介護ソフトの品質を長期的に守るには、リリースのたびにテストケースを一から考える方法では限界があります。 介護報酬の改定や外部システムの仕様変更が発生すると、自社で直接変更した機能だけでなく、そのデータを参照する帳票や請求、連携機能まで影響を受ける可能性があります。 さらに、LIFEでは介護ソフト向けのCSV連携仕様が継続して更新されており、2026年5月にも関連仕様が更新されています。 介護情報基盤についても2026年7月に連携用インタフェース仕様書第2.1版が公開されているため、外部仕様の変更を検知し、自社への影響を確認する仕組みが重要になっています。 そこで必要になるのが、 変更影響分析、シナリオテスト、回帰テスト、自動化、業務担当者とのレビュー を組み合わせたテスト体制です。 個々の担当者の経験だけに依存せず、「変更されたらどこを見るか」をチームで再利用できる形にしておくことで、制度変更が続いても品質を安定させやすくなります。 介護報酬改定は「変更された数字」だけをテストしない！ 介護報酬改定への対応では、変更された単位数だけ確認すれば十分というわけではありません。 算定条件、加算、適用時期、関連する通知、帳票など、変更によって影響を受ける範囲を広く確認する必要があります。 2026年度の介護報酬改定でも、算定基準に関する告示や通知などが改正されています。 テスト設計では、まず制度変更の内容とシステムの機能を対応付け、 どの変更がどの画面・計算・帳票・データ出力へ影響するのか を一覧化します。 そのうえで、直接修正した機能だけでなく、そのデータを利用する後続機能までテスト対象へ広げます。 特に重要なのが、新旧ルールの切り替えです。 改定日前日、改定日当日、改定日翌日のデータを作成し、それぞれに正しいルールが適用されるかを確認します。 また、改定前から利用している利用者と改定後に登録した利用者が混在するケースなども検証すると、実運用に近い確認ができます。 「変更箇所をテストする」のではなく、「変更によって結果が変わる場所をすべて探す」 ことが制度改定テストのポイントです。 LIFE・ケアプラン・介護情報基盤は「ファイルが出た」で終わらせない！ 介護ソフトは、自社システムだけで業務が完結するとは限りません。 LIFE、ケアプランデータ連携、介護情報基盤など、外部システムとの間でデータを受け渡す場面が増えています。 LIFEではCSV連携の標準仕様が継続して更新されており、介護ソフト側でも最新仕様へ追随する必要があります。 介護情報基盤についてもAPI（Application Programming Interface：システム同士が情報をやり取りするための仕組み）やインタフェースに関する仕様が整備されています。 外部連携テストでは、「CSVファイルが出力できた」というところで終わらせず、 入力元→データ変換→ファイルやAPIへの出力→送信→外部側での取り込み まで一つの流れとして確認します。 必須項目、桁数、コード値、文字コード、データ形式、仕様バージョンなども確認対象です。 さらに、欠損データ、不正コード、重複データ、旧形式のデータを送った場合のエラー処理もテストします。 通信失敗時に適切なエラーが表示されるか、再送によってデータが重複しないかまで確認しておくと、外部連携時のトラブルを減らしやすくなります。 機能単位から卒業！「記録から請求まで」のシナリオテストを作ろう 介護ソフトのテスト品質を高めるには、機能一覧からテストケースを作るだけでなく、 実際の介護業務を一つのストーリーとして再現する方法 が有効です。 たとえば、利用者を新規登録し、認定情報を設定し、ケアプランを作成し、サービス予定を登録します。 その後、実際にサービスを提供した想定で介護記録を入力し、実績を確定させ、加算の条件を満たしているかを確認し、帳票と請求データを作成します。 この一連の処理を通すことで、一つひとつの機能テストでは気付きにくいデータ連携の不整合を発見しやすくなります。 さらに、予定通り進むケースだけでなく、途中でサービスをキャンセルする、担当職員を変更する、記録を修正する、認定情報を更新するといったイベントを加えます。 画面表示だけを見るのではなく、帳票、外部出力、請求結果などを突き合わせて整合性を確認することも重要です。 本番環境で発生した問い合わせや障害についても、同じ条件を再現するシナリオを作り、回帰テストへ追加します。 こうして 現場で実際に起きた問題をテスト資産へ変えていく ことで、同じ不具合の再発を防ぎやすくなります。 回帰テストを仕組み化！制度変更のたびにゼロから確認する状態をなくそう 新しい機能を追加したり制度改定へ対応したりした際には、修正した部分だけではなく、既存機能が壊れていないかを確認する回帰テストが必要です。 介護ソフトでは各機能がデータでつながっているため、一見関係のなさそうな変更が請求や帳票へ影響するケースも考えられます。 まず、利用者情報、介護記録、実績、請求、権限、帳票、外部連携など、 リリースごとに必ず確認する重要機能 を固定します。 さらに、過去に発生した重大障害や問い合わせの多かった機能も回帰テストへ追加します。 変更が発生した際には、「直接修正した機能」と「そのデータを参照している機能」を分けて影響範囲を整理すると、確認漏れを防ぎやすくなります。 何度も同じ手順を繰り返すテストについては、自動化も有効です。 一方で、使いやすさや複雑な介護業務の判断など、人が確認した方が適している部分まで無理に自動化する必要はありません。 自動化率を高めることではなく、重要な不具合を早く検知できる状態を作ること を目的に、自動テストと手動テストを使い分けます。 テスト担当だけで抱えない！介護業務・開発・品質保証が一緒に品質を守ろう 介護ソフトでは、テスト技術だけで品質を守ることは難しく、介護業務や制度に関する知識も欠かせません。 一方で、QA（Quality Assurance：品質保証）担当者が介護制度のすべてを一人で理解するのも現実的ではありません。 そこで、開発担当者、QA担当者、プロダクト担当者、介護業務に詳しい担当者などが、それぞれの知識を持ち寄って品質を確認する体制を作ります。 テストケースを実行する直前だけではなく、 要件や仕様を決める段階から品質確認へ参加すること が重要です。 業務担当者にシナリオをレビューしてもらうことで、システム担当者だけでは思い付かなかった現場特有のケースを発見できる場合があります。 逆に、実際には発生しない複雑な組み合わせを削り、重要なケースへテスト工数を集中させることもできます。 リリース後には、不具合件数だけでなく、問い合わせ内容や現場で困った操作なども振り返ります。 その結果を仕様書やテストケースへ戻し、次回以降も確認できる状態にします。 制度変更の履歴、判断根拠、障害事例、テスト観点をチームの共有資産として残す ことで、担当者が変わっても品質を維持しやすくなります。 まとめ｜介護業務の流れから考えれば、重大な不具合を防ぐテストができる！ 介護業界のソフトウェアテストでは、個々の画面が正常に動くことだけを確認しても十分ではありません。 利用者情報、アセスメント、ケアプラン、介護記録、サービス実績、帳票、介護報酬請求、外部連携まで、 一つのデータが介護業務の中をどのように流れていくのか を追うことが重要です。 特に請求金額の誤り、介護記録の欠損、個人情報の誤表示、外部システムへの誤ったデータ送信などは影響が大きいため、優先的に確認する必要があります。 また、正常系だけでなく、月末・月初、制度切り替え日、予定変更、過去データの修正、通信断など、実際の業務で起こり得る条件もテストへ取り入れます。 介護報酬やLIFE、介護情報基盤などの仕様は変化するため、一度テストケースを作って終わりではありません。 変更による影響範囲を整理し、重要機能を回帰テストとして残し、本番で発生した問題を新しいテストケースへ反映する仕組みが必要です。 介護業務の専門知識をQA担当者だけで抱えず、開発や業務担当者と共有しながら品質を確認することも欠かせません。 まずは 「この画面へ入力した情報が、最終的にどの帳票・請求・外部システムへつながっているのか」 を一本の業務フローとして整理するところから始めると、介護ソフト特有のテスト観点を見つけやすくなります。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

クラウドコンピューティングの初期の頃、AWS は世界中の都市で AWS Pop-up Lofts と呼ばれる物理的なスペースで建設業者を対象とした集中学習をサポートしていました。これらのスペースは、スタートアップ起業家、開発者、およびイベント、ミーティング、共同作業で AWS についてもっと知りたいと考えている人が利用できました。最近の生成 AI の登場により、 AWS Gen AI Lofts は世界中でポップアップスタイルのコラボレーションスペースを提供し、スタートアップや開発者に没入型の体験を提供しました。 私たちは、実践的な体験、コミュニティ主導の共有、技術的なコラボレーションを通じて、学生や開発者が学び、つながり、貢献できる常設のコミュニティスペースが必要であることに気づきました。2025 年 7 月にサンフランシスコでオープンして以来、最初の AWS Builder Loft は 22,500 人以上の開発者を迎え、地元の技術コミュニティが一堂に会するハッカソン、ワークショップ、デモナイト、コミュニティ主導のイベントを開催してきました。 2026 年 8 月 18 日、ベルリン、ハイデラバード、サンパウロに新しいビルダーロフトをオープンする計画を発表しました。各場所は、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ制作スペース、コラボレーション/コワーキングエリア、イベント主催を提供する常設コミュニティスペースとなり、ドアを通り抜けたい開発者、学生、技術専門家向けに、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ作成スペース、コラボレーション/コワーキングエリア、イベントの開催が可能になります。 そこでは引き続き AWS の専門家に会うことができますが、それ以上に、 AWS User Groups や AWS Student Builder Groups 、すでに参加している独立した開発者グループまで、地域の技術コミュニティの本拠地を作りたいと考えています。テクノロジーコミュニティのリーダーとして、ミートアップを開催するためのスペースの予約を無料でリクエストしていただけます。 なぜ 3 都市なのか この拡張は、各地域の重要な人材とイノベーションの拠点である開発都市が急成長していることを反映しています。 ベルリン : AWS European Sovereign Cloud を立ち上げた後、私たちはヨーロッパの開発者コミュニティへの取り組みを深めています。ベルリンの Builder Loft は、デジタル主権に関する教育セッション、ハッカソン、セキュリティ対策ワークショップ、コミュニティミートアップを開催し、ドイツの成長を続けるスタートアップエコシステムと、より広範なヨーロッパおよび世界のテクノロジー環境をつなぐコミュニティミートアップを開催します。 ハイデラバード : Hyderabad Builder Loft は、インドの開発者に AI のスキルアップ、クラウドネイティブアーキテクチャの探求、次世代アプリケーションを構築する仲間との交流のための専用スペースを提供します。 サンパウロ : ブラジルのクラウド市場は毎年 30 % の成長を遂げており、サンパウロはラテンアメリカのテクノロジーブームの中心に位置しています。Builder Loft は、地域の開発者のハブとして機能し、地域社会、大学、スタートアップネットワークと連携して無料のプログラミングを提供します。 ビルダーロフトでの典型的な一週間 サンフランシスコの Builder Loft では、生成 AI に関する技術的なディープダイブからスタートアップのピッチナイト、学生向けのコーディングワークショップから地域全体の開発者が集まるネットワーキングセッションまで、毎週 4 〜 8 件のコミュニティイベントを開催しています。 スペースは柔軟に設計されています。火曜日の朝、トレーニングルームは 50 人以上の学生でいっぱいになります。夕方になると、スタートアップが潜在的なコラボレーターの部屋に最新のプロトタイプを披露するデモステージに変わります。週末には、コミュニティグループが独自のミートアップを開催します。 このモデルが機能する理由は、コミュニティ自体によって推進されているということです。地元の開発者、ミートアップ主催者、技術リーダーがプログラミングを形作ります。AWS はスペース、インフラストラクチャ、サポートを提供しますが、エネルギーは参加するビルダーから得られます。 今後のイベント を検索するか、サンフランシスコの Builder Loft での 独自のイベントの開催 をリクエストしてください。 ご期待ください Builder Loft は、今後のブログ記事で 3 都市でのオープンについて発表しますので、最新情報にご期待ください！ Builder Lofts の詳細を確認したり、最新情報を入手したりするには、 Rick のブログ投稿 と AWS Builder Loft のページ をご覧ください。 – Channy 原文は こちら です。