介護ソフトのテストを任されたものの、「一般的な業務システムと同じ観点で確認してよいのだろうか」と迷うケースは少なくありません。 介護ソフトには利用者情報の管理だけでなく、アセスメント、ケアプラン、介護記録、サービス実績、各種帳票、介護報酬請求など、介護現場のさまざまな業務が集約されています。 そのため、個々の画面が仕様通りに動いていることだけを確認しても、十分なテストとはいえません。 たとえば、介護記録への入力自体は正常でも、その情報がサービス実績や帳票、請求処理へ正しく反映されなければ、現場では重大な問題につながります。 さらに介護分野では、介護報酬改定によって算定基準や通知などが変更されたり、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 原文は こちら です。

本ブログは 2024 年 1 月 26 日に公開された AWS Blog “ Export a Software Bill of Materials using Amazon Inspector ” を翻訳したものです。 Amazon Inspector は、 Amazon Web Services (AWS) ワークロードのソフトウェアの脆弱性と意図しないネットワークの露出を継続的にスキャンする、自動化された脆弱性管理サービスです。Amazon Inspector の機能が拡張され、 Windows EC2 インスタンス を除く、Amazon Inspector がモニタリングするサポート対象リソースの統合された ソフトウェア部品表 (SBOM) をエクスポートできるようになりました。 訳注: 本記事公開後の 2026 年 2 月 28 日より、エージェントレス方式でスキャンされる Windows EC2 インスタンスの SBOM エクスポートがサポートされました。エージェントベース方式の Windows EC2 インスタンスは引き続き対象外です。詳細は「 Amazon Inspector による SBOM のエクスポート 」を参照してください。 お客様からは、Amazon Inspector がモニタリングするリソースから収集したソフトウェアアプリケーションのインベントリを追加で提供してほしいというご要望をいただいていました。これにより、現在の Amazon Inspector の検出結果に関連する可能性のあるソフトウェアサプライチェーンやセキュリティ上の脅威を追跡できるようになります。SBOM を生成すると、最も頻繁に使用しているパッケージや、組織全体に影響を及ぼす可能性のある関連する脆弱性など、ソフトウェアサプライチェーンの詳細を可視化する重要なセキュリティ情報が得られます。 このブログ記事では、組織全体で Amazon Inspector がモニタリングするリソースの統合された SBOM を、 CycloneDx や SPDX といった業界標準形式でエクスポートする手順を紹介します。また、 Amazon Athena を使用して SBOM アーティファクトを分析するためのアプローチと、そこから得られる洞察についても共有します。 概要 SBOM は、ソフトウェアコンポーネントを構成する要素のリストを含む、ネストされたインベントリとして定義されます。セキュリティチームは、Amazon Inspector の AWS マネジメントコンソールにあるリソースカバレッジページから、組織全体の統合された SBOM を Amazon Simple Storage Service (Amazon S3) にエクスポートできます。 CycloneDx や SPDX の業界標準形式を使用することで、SBOM から得られる洞察をもとに、組織全体でどのソフトウェアパッケージを更新する必要があるか、他に選択肢がない場合はどのパッケージを廃止するかといった意思決定を行えます。個々のアプリケーションエンジニアやセキュリティエンジニアは、コンソールまたはアプリケーションプログラミングインターフェイス (API) の SBOM エクスポートワークフローの中で、特定のアカウント、リソースタイプ、リソース ID、タグ、またはこれらの組み合わせによるフィルターを適用して、単一のリソースやリソースグループの SBOM をエクスポートすることもできます。 SBOM のエクスポート Amazon Inspector の SBOM レポートを S3 バケットにエクスポートするには、SBOM レポートのエクスポート先となる AWS リージョンにバケットを作成して設定する必要があります。Amazon Inspector のみがバケットに新しいオブジェクトを配置できるように、 バケットのアクセス許可を設定 する必要があります。これにより、他の AWS サービスやユーザーがバケットにオブジェクトを追加できないようにします。 各 SBOM レポートは S3 バケットに保存され、指定したエクスポート形式に応じて Cyclonedx_1_4 (Json) または Spdx_2_3-compatible (Json) という名前が付けられます。また、 S3 イベント通知 を使用して、新しい SBOM レポートがエクスポートされたことを各運用チームに通知することもできます。 Amazon Inspector では、SBOM レポートの暗号化に AWS Key Management Service (AWS KMS) キーを使用する必要があります。このキーはカスタマーマネージドの対称暗号化 AWS KMS キーであり、SBOM レポートの保存用に設定した S3 バケットと同じリージョンにある必要があります。SBOM レポート用の新しい AWS KMS キーには、Amazon Inspector がキーを使用できるようアクセス許可を付与する キーポリシー を設定する必要があります (図 1 を参照)。 図 1: Amazon Inspector の SBOM エクスポート 訳注: 現在は、バージョン範囲指定などにより特定の名前・バージョンに解決できないパッケージ (未解決ハッシュ) も SBOM エクスポートに含まれるようになりました。これらのパッケージは脆弱性スキャンの対象にはなりませんが、ハッシュ値がエクスポートされたコンポーネント一覧に記録されます。 前提条件のデプロイ 提供されている AWS CloudFormation テンプレートは S3 バケットを作成し、Amazon Inspector が SBOM レポートオブジェクトをそのバケットにエクスポートできるようにするバケットポリシーを関連付けます。このテンプレートは、SBOM レポートのエクスポートに使用する新しい AWS KMS キーも作成し、Amazon Inspector サービスにキーを使用するアクセス許可を付与します。 エクスポートは、 Amazon Inspector の委任された管理者アカウント または Amazon Inspector の管理者アカウント自体から開始できます。これにより、S3 バケットには Amazon Inspector のメンバーアカウントのレポートが格納されます。同じリージョンにデプロイされた Amazon Inspector から SBOM レポートをエクスポートするには、CloudFormation テンプレートがその AWS アカウントとリージョン内にデプロイされていることを確認してください。複数のアカウントで Amazon Inspector を有効にしている場合は、Amazon Inspector が有効になっている各リージョンに CloudFormation スタックをデプロイする必要があります。 CloudFormation テンプレートをデプロイするには 次の Launch Stack ボタンを選択して、アカウントで CloudFormation スタックを起動します。 テンプレートのスタック名とパラメータ ( MyKMSKeyName と MyS3BucketName ) を確認します。S3 バケット名は一意である必要がある点に注意してください。 [次へ] を選択して、スタックのオプションを確認します。 次のページに進み、 [送信] を選択します。CloudFormation スタックのデプロイには 1～2 分かかります。 CloudFormation スタックのデプロイが正常に完了したら、スタックによって作成された S3 バケットと AWS KMS キーを使用して SBOM レポートをエクスポートできます。 SBOM レポートのエクスポート セットアップが完了したら、SBOM レポートを S3 バケットにエクスポートできます。 コンソールから SBOM レポートをエクスポートするには S3 バケットと AWS KMS キーを作成したのと同じリージョンの Amazon Inspector コンソールに移動します。 ナビゲーションペインから [SBOMs] を選択します。 フィルターを追加 して、リソースの特定のサブセットのレポートを作成します。フィルターを指定しない場合は、アクティブでサポート対象のすべてのリソースの SBOM がエクスポートされます。 希望するエクスポートファイルタイプを選択します。オプションは Cyclonedx_1_4 (Json) または Spdx_2_3-compatible (Json) です。 CloudFormation テンプレートの出力セクションにある S3 バケット URI を入力し、作成した AWS KMS キーを入力します。 [エクスポート] を選択します。エクスポートするアーティファクトの数に応じて、完了までに 3～5 分かかることがあります。 図 2: SBOM エクスポートの設定 エクスポートが完了すると、すべての SBOM アーティファクトが S3 バケットに格納されます。S3 バケットから SBOM アーティファクトをダウンロードすることも、 Amazon S3 Select を使用して標準 SQL クエリでオブジェクトからデータのサブセットを取得することもでき、柔軟に活用できます。 図 3: Amazon S3 Select 訳注: Amazon S3 Select は新規のお客様には提供されていません (すでにご利用のお客様は引き続き利用できます)。同等の処理には、本記事で後述する Amazon Athena の利用を検討してください。 また、 Amazon Athena を使用して高度なクエリを実行したり、 Amazon QuickSight を使用してダッシュボードを作成したりすることで、洞察を得たり傾向を把握したりすることもできます。 クエリと可視化 Athena を使用すると、S3 バケットに保存されている生データに対して SQL クエリを実行できます。Amazon Inspector のレポートは S3 バケットにエクスポートされます。「 AWS Glue クローラーの追加 」のチュートリアルに従って、テーブルを作成しデータをクエリできます。 AWS Glue が S3 データをクロールできるようにするには、AWS Glue クローラーのチュートリアルに記載されているロールを AWS KMS キーのアクセス許可に追加して、AWS Glue が S3 データを復号できるようにする必要があります。 以下は、ユースケースに合わせて更新できるポリシー JSON の例です。AWS アカウント ID の <111122223333> と S3 バケット名の <DOC-EXAMPLE-BUCKET-111122223333> は、必ずお客様自身の情報に置き換えてください。 { "Sid": "Allow the AWS Glue crawler usage of the KMS key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: <111122223333> :role/service-role/AWSGlueServiceRole-S3InspectorSBOMReports" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey*" ], "Resource": "arn:aws:s3::: <DOC-EXAMPLE-BUCKET-111122223333> " }, 注: AWS Glue 用に作成されたロールには、クローラーを作成するために、レポートのエクスポート先である S3 バケットを読み取るアクセス許可も必要です。AWS Glue の AWS Identity and Access Management (IAM) ロールによって、クローラーの実行と Amazon S3 データストアへのアクセスが許可されます。 AWS Glue データカタログを構築した後は、クローラーをスケジュール実行するように設定することで、S3 バケットにエクスポートされる最新の Amazon Inspector の SBOM マニフェストを常に反映した状態に保つことができます。 さらに、クローラーによって追加されたテーブルに移動し、Athena でデータを表示できます。Athena を使用すると、Amazon Inspector のレポートに対してクエリを実行し、環境に関連する出力データを生成できます。生成される SBOM レポートのスキーマは、レポート内の特定のリソース ( Amazon Elastic Compute Cloud (Amazon EC2) 、 AWS Lambda 、 Amazon Elastic Container Registry (Amazon ECR) ) によって異なります。そのため、スキーマに応じて、レポートから情報を取得する Athena の SQL クエリを作成できます。 以下は、SBOM レポート内のリソースについて上位 10 件の脆弱性を特定する Athena クエリの例です。レポートに含まれる CVE (共通脆弱性識別子) を使用して、CVE の影響を受ける個々のコンポーネントを一覧表示できます。 SELECT account, vuln.id as vuln_id, count(*) as vuln_count FROM <Insert_table_name>, UNNEST(Inset_table_name.vulnerabilities)as t(vuln) GROUP BY account, vuln.id ORDER BY vuln_count DESC LIMIT 10; 以下の Athena クエリの例では、上位 10 件のオペレーティングシステム (OS) を、リソースタイプおよびその数とともに特定できます。 SELECT resource, metadata.component.name as os_name, count(*) as os_count FROM <Insert_table_name> WHERE resource = 'AWS_LAMBDA_FUNCTION' GROUP BY resource, metadata.component.name ORDER BY os_count DESC LIMIT 10; 重大な脆弱性を持つパッケージがあり、そのパッケージがプライマリパッケージとして使用されているのか、依存関係として追加されているのかを知りたい場合は、以下の Athena のサンプルクエリを使用して、アプリケーション内のパッケージを確認できます。この例では、Log4j パッケージを検索しています。結果として account ID 、 resource type 、 package_name 、 package_count が返されます。 SELECT account, resource, comp.name as package_name, count(*) as package_count FROM <Insert_Table _name>, UNNEST(<Insert_Table_name>.components) as t(comp) WHERE comp.name = 'Log4j' GROUP BY account, comp.name, resource ORDER BY package_count DESC LIMIT 10 ; 注: サンプルの Athena クエリは、SBOM エクスポートレポートのスキーマに応じてカスタマイズする必要があります。 このソリューションをさらに拡張するには、 Amazon QuickSight を使用して AWS Glue テーブルに接続し、データを可視化するダッシュボードを作成できます。 訳注: Amazon QuickSight は 2025 年 10 月に Amazon Quick Suite へ進化 し、現在は Amazon Quick として提供されています (BI 機能は Quick Sight コンポーネントとして存続し、既存の API や連携は変更なく動作します)。また、本記事の発展形として、Lambda と Amazon EventBridge によるエクスポートの自動化からダッシュボードでの可視化までを実装した「 Enhance container software supply chain visibility through SBOM export with Amazon Inspector and QuickSight 」も公開されています。 まとめ Amazon Inspector の新しい SBOM 生成機能は、複数レベルの依存関係にわたるソフトウェアパッケージのリストを提供することで、ソフトウェアサプライチェーンの可視性を向上させます。また、SBOM を使用して各ソフトウェアパッケージのライセンス情報をモニタリングし、組織内の潜在的なライセンス違反を特定することで、潜在的な法的リスクの回避にも役立ちます。 SBOM エクスポートの最も重要なメリットは、業界の規制や標準への準拠を支援できることです。業界標準の形式 (SPDX と CycloneDX) を提供し、他のツール、システム、サービス (Nexus IQ や WhiteSource など) との容易な統合を可能にすることで、インシデント対応プロセスの効率化、セキュリティ評価の正確性と速度の向上、規制要件へのコンプライアンスの維持を実現できます。 これらのメリットに加えて、SBOM エクスポート機能は、リソース内で検出された OS パッケージやソフトウェアライブラリの把握にも役立ち、業界の規制や標準への準拠をさらに強化します。   この記事で共有した情報に関するご質問がある場合は、 Amazon Inspector re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせ ください。 Varun Sharma Varun は、セキュリティのマントを誇らしげにまとう AWS クラウドセキュリティエンジニアです。Amazon Cognito と IAM の謎を解き明かす才能を持ち、これらのサービスの頼れる専門家です。クラウドのセキュリティ確保の手を休めているときは、セキュリティペネトレーションテストの世界に没頭しています。そして画面から離れているときは、気分を切り替えて、カメラのレンズを通して自然の美しさを捉えています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。