介護ソフトのテストを任されたものの、「一般的な業務システムと同じ観点で確認してよいのだろうか」と迷うケースは少なくありません。 介護ソフトには利用者情報の管理だけでなく、アセスメント、ケアプラン、介護記録、サービス実績、各種帳票、介護報酬請求など、介護現場のさまざまな業務が集約されています。 そのため、個々の画面が仕様通りに動いていることだけを確認しても、十分なテストとはいえません。 たとえば、介護記録への入力自体は正常でも、その情報がサービス実績や帳票、請求処理へ正しく反映されなければ、現場では重大な問題につながります。 さらに介護分野では、介護報酬改定によって算定基準や通知などが変更されたり、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 では、AI を活用した新しいソフトウェア開発手法「 AI-DLC（AI-Driven Development Life Cycle） 」を提唱しています。AI-DLC は、AI を単なる補助ツールとしてではなく、要件定義から設計・実装・テストまでの開発ライフサイクル全体に組み込みながら、人間が主導権を握る（Human-in-the-Loop）ことを前提とした開発手法です。この AI-DLC を短期間で体験・実践いただくワークショップが「AI-DLC Unicorn Gym（以下 UG）」です。 2026 年 6 月 11 日〜12 日、株式会社サンリオ デジタル事業開発部の皆様と 2 日間の「サンリオ AI-DLC UG」を開催しました。本記事では、開催レポートと、参加メンバーの皆様に体験を語っていただいた座談会の様子をお届けします。 1. サンリオ AI-DLC Unicorn Gym 開催レポート サンリオ AI-DLC Unicorn Gym 参加メンバー サンリオのデジタル事業開発部は、「キャラフォリオ」（公式とファンがつながる創作プラットフォーム）や「オモイデバッジ」（イベント参加記録・ユーザー交流 SNS）など、デジタルプロダクトの企画・開発を担っています。2025 年から開発の内製化に舵を切り、少数精鋭のチームで Claude Code を中心とした AI 活用開発を実践してきました。個人の生産性向上の先にある「チームとして、上流工程からどう AI を組み込むか」という課題への答えを求めて AI-DLC に着目されたことが、今回の開催のきっかけです。 当日はデジタル事業開発部 プロダクト開発課 シニアマネージャー 倉井 龍太郎 氏をはじめとする 2 チーム 6 名のエンジニアとプロダクトマネージャーが参加し、実際のプロダクトを題材に AI-DLC の全フェーズを体験しました。ツールには Kiro を利用し、AI エージェントを中心に据えた開発ワークフローを実践しています。AWS 側はアカウントマネージャーの荻原 賢大、ソリューションアーキテクトの山澤 良介・瀧田 直斗が各チームに伴走しました。 チーム テーマ 技術構成 成果 チーム A （オモイデバッジ） オモイデバッジ 管理機能拡張 — パッケージ詳細への URL リンク設置 TypeScript / Kiro inception から本番マージまで 約 5 時間 で完了。デプロイ済み。 チーム B （新規アプリ） 新規アプリの立ち上げ TypeScript / Kiro 管理者向け管理画面まで構築完了 チーム A の成果 — 「作らない」判断と、約 5 時間での本番マージ チーム A では 2 つのユーザーストーリーを検討しました。1 つ目は、AI と一緒に価値と実現方法を掘り下げた結果「機能を実装しなくても運用でカバーできる」と判断し、あえて実装しないことを選択。AI で実装が速くなるほど「何を作らないか」の判断に価値が生まれることを示す成果となりました。 2 つ目のストーリー「パッケージ詳細への URL リンク設置」では、AI-DLC の全フェーズを一気通貫で体験しました。 時刻 フェーズ 内容 Day 2 10:59 Inception インタビュー型の add-inception スキルを作成 Day 2 13:59 Inception AI のインタビューを受けて inception ドキュメントを作成・マージ Day 2 15:03 Construction 既存の設計スキルで設計書を作成し、自律実装へ Day 2 15:58 マージ backend / API / 管理画面 / アプリの実装をマージ inception 開始から本番マージまで 約 5 時間 2. 座談会 — 参加メンバーに聞く 荻原（AWS） 今回の AI-DLC UG が実現した経緯を教えてください。 倉井氏（サンリオ） 日頃から Claude Code を使って開発していましたが、個人の生産性は上がっても「チームとして、上流工程からどう AI を組み込むか」がずっと課題でした。AWS の AI-DLC のブログを見つけたとき、まさにこれだと思って、すぐにミーティングで相談しました。 荻原（AWS） AI にインタビューされながらユーザーストーリーを作るプロセスはどうでしたか。 チーム A メンバー（サンリオ） 「何を・誰に・どんな価値を・どう検証するか」を AI が順番に聞いてくれるので、抜け漏れを防げました。価値のコンフリクトや成功指標など、一人では飛ばしがちな観点を確実に通過できたのが大きいです。またインタビューをスキル化し、改善ステップも組み込んだので、誰がやっても同じ品質のインセプションプロセスを踏めるようになりました。 荻原（AWS） AI-DLC を体験したことで、今後の開発にどう活かしていきたいですか。 倉井氏（サンリオ） 大きく 2 つあります。1 つ目は、インセプションプロセスで言語化することで、企画側の目的をしっかり理解した上で開発が進められ、手戻りを大幅に減らせること。2 つ目は、ユーザーストーリーを書くことでプロジェクトメンバー全員が同じ情報を持った上で開発が進むことです。非常にスムーズでした。 チーム A メンバー（サンリオ） 今後は実際の開発フローに PM の作業も組み込みたいと考えています。PM・エンジニアの「作業」をエージェントに任せて、人間は設計とレビューに専念する — それが目指す姿です。 倉井氏（サンリオ） 内製化を進める中で「少人数でいかに大きな価値を届けるか」が常に課題です。AI-DLC はそのための方法論として非常に手応えを感じました。AI-DLC の旅はまだ始まったばかりです。 3. 今後の展開と AWS の支援 サンリオ デジタル事業開発部では、今回の UG で得た知見を実プロダクト開発に本格導入していく予定です。 Inception の標準化 — 今回作成したインタビュー型スキルをチーム標準プロセスとして運用開始 「人間は設計とレビュー」モデルの実践 — AI が実行し、人間が監視・判断する AI-DLC の本質を日常の開発に浸透させる ワークショップを運営して感じたのは、AI-DLC の Inception フェーズが Amazon の Working Backwards （お客様の体験から逆算して考える手法）と本質を同じくする、ということです。「誰に・どんな価値を・なぜ届けるのか」を AI のインタビューに答えながら言語化し、チーム全員で合意する。AI が「問い」を投げかけることで議論の抜け漏れが構造的に防げるため、経験の浅いチームでも質の高い要件定義ができるようになります。 AWS は、サンリオの AI 活用パートナーとして、UG で作成したスキルの実プロダクトへの適用と AI 駆動開発の定着を引き続き支援してまいります。倉井氏をはじめ、ご参加いただいた皆様、ありがとうございました。 本記事は、2026 年 6 月 11 日〜12 日に開催した「サンリオ AI-DLC Unicorn Gym」および参加メンバーの皆様との座談会をもとに構成しました。 著者プロフィール 荻原 賢大 アマゾン ウェブ サービス ジャパン合同会社 営業部 広域事業部門。株式会社サンリオを担当するアカウントマネージャー。お客様のビジネス変革を技術で支援することに情熱を注いでいます。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への展開にも取り組んでいます。 山澤 良介 AWS のソリューションアーキテクトとして、製造業を中心にエンタープライズ企業の支援をしています。その活動の傍ら、最近は Claude Code / Cowork の国内展開に向けた技術支援やコンテンツ作成に取り組んでいます。

本記事は 2026 年 8 月 20 日 に公開された「 Long-term system tables retention in Amazon Redshift with Amazon S3 Tables 」を翻訳したものです。 Amazon Redshift のシステムテーブルは、実行されたすべてのクエリ、確立されたすべての接続といった運用シグナルを継続的に記録します。収集したデータは、データウェアハウス全体の可観測性、パフォーマンス分析、コンプライアンス監査を支えます。しかしこれまで、システムテーブルがこの重要なデータを保持できる期間はわずか 7 日間で、独自の回避策なしに長期的なコンプライアンス対応や監査を行うのは困難でした。 Amazon Simple Storage Service ( Amazon S3 ) の機能である Amazon S3 Tables と Amazon Redshift システムテーブル の統合により、システムテーブルのログデータが自動的に Amazon S3 Tables に配信され、 Apache Iceberg 形式で保存されます。Amazon Redshift システムテーブルの保持期間を現在の 7 日間の上限を超えて設定でき、独自の ETL パイプラインやクラスターリソースを消費することなく、コンプライアンス対応、監査、ウェアハウス横断の可観測性を長期にわたって実現できます。データはオープンかつ堅牢で、Amazon Redshift、 Amazon Athena 、 AWS Glue 、 Amazon EMR 、その他の Apache Iceberg 対応エンジンからクエリできます。 本記事では、Amazon Redshift システムテーブルの統合がどのようにログデータを Amazon S3 Tables に配信するのかを解説します。本機能は、RA3 および RG のプロビジョンドクラスターと Amazon Redshift Serverless ワークグループでサポートされています。 課題 Amazon Redshift を運用していると、システムテーブルの保持期間が 7 日間に制限されていることに起因する運用上の課題によく直面します。 クエリの傾向が把握しにくい: 同じクエリの 30 日前と現在のパフォーマンスを比較したいことがあります。パフォーマンスが徐々に変化する場合、長期的なベースラインがあれば、場当たり的なトラブルシューティングではなく、データに基づいた根本原因分析が可能になります。 変更前後の比較: 新しいワークロードの追加、インスタンスタイプの変更、 Workload Management (WLM) キューの調整を行う際には、その影響を正確に測定したくなります。保持期間を延長すれば、必要なベースラインデータを残しておけます。 季節性を考慮したキャパシティプランニング: 月末のスパイク、四半期末の急増、年間のピークを把握して計画するには、数か月分の履歴データが必要です。保持期間を延長すると、数か月から数年にわたる季節的なパターンが見えてきます。 独自 ETL パイプラインの負荷: 保持期間の制限を回避するため、システムテーブルのデータを 1 時間ごとまたは 1 日ごとに Amazon Redshift マネージドストレージ内の永続テーブルにコピーする独自パイプラインを構築するチームもあります。こうしたパイプラインはクラスターリソースを消費し、本番ワークロードと競合し、継続的なエンジニアリング保守を必要とします。Amazon Redshift がシステムテーブルのスキーマやデータ共有の設定を更新すると、パイプラインには手作業での対応が必要になり、記録に欠落が生じます。 コンプライアンス要件: 規制対象の業界では、数か月から数年に及ぶ監査証跡の保持が求められます。7 日間の上限のもとでこの要件を満たすには、独自のインフラが必要でした。Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、この課題が解決されます。 仕組み Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、Amazon Redshift システムテーブルのデータを Apache Iceberg 形式で自動的に Amazon S3 テーブルに書き込むフルマネージド機能です。パーティショニング、圧縮、保持期間の管理は AWS が自動的に処理します。ログの書き込み処理は独立したバックグラウンドプロセスで実行され、本番ワークロードとのリソース競合を抑えます。パイプラインの管理は AWS が代行します。 本機能はリリース時点で 25 を超えるシステムビューをサポートしています。サポート対象のシステムビューについては ドキュメント を参照してください。 セットアップ Amazon Redshift コンソールから Amazon S3 Tables とのシステムテーブル統合を有効にするには、次の手順に従います。 Amazon Redshift コンソールを開き、[System table integrations] ページに移動します。プロビジョンドクラスターまたは Serverless ワークグループの詳細ページからもアクセスできます。 Create System table integration を選択します。設定ウィザードが起動します。 本機能を有効にする Amazon Redshift プロビジョンドクラスターまたは Amazon Redshift Serverless ワークグループを選択します。   図 1: システムテーブル統合ウィザードでの Amazon Redshift データウェアハウスの選択 Available system tables リストから公開するシステムビューを選択します。個々の SYS_* ビューを選ぶか、 Select all supported system tables を選択して、現在および将来サポートされるすべてのビューを公開します。すべてを選択した場合、将来追加される新しいビューは設定を変更しなくても自動的に含まれます。   図 2: [Available system tables] リストから公開するシステムビューを選択 デプロイモデルを選択します。Amazon S3 Tables でのデータの整理方法を選びます。 データウェアハウスごと・システムテーブルごとに個別の S3 テーブル : 各ウェアハウスのデータを専用のテーブル群に保持します。 データウェアハウス横断でシステムテーブルごとに共有の S3 テーブル : アカウント内の複数のウェアハウスのデータを共有のテーブル群に集約します。 必要に応じて、AWS Key Management Service (AWS KMS) のカスタマーマネージドキーで暗号化を設定します。デフォルトでは、データは Amazon S3 マネージドキー (SSE-S3) で暗号化されます。 変更を保存します。Amazon Redshift は選択したビューの Amazon S3 Tables への公開を開始し、一定の間隔で新しいレコードを追加し続けます。 統合が有効になっているかを確認するには、次のようにします。 クラスターまたはワークグループの詳細ページに移動します。 統合のステータスと、各ビューの最終取り込み時刻を確認します。 公開されたデータは Amazon S3 Tables コンソールからも確認できます。 有効化すると、Amazon Redshift は本番ワークロードとは別の独立したバックグラウンドプロセスを通じて、定期的にログデータを Amazon S3 テーブルに書き込みます。保持されたログのクエリを開始するには、AWS Glue Catalog を介して Amazon Redshift 環境と Amazon S3 Tables のデータを接続する初回セットアップが必要です。次の手順を実行します。 AWS Glue Data Catalog と Amazon S3 Tables へのアクセスに必要な権限を持つ AWS Identity and Access Management (IAM) ロールを作成し、Amazon Redshift クラスターまたは Amazon Redshift サーバーレスネームスペースに関連付けます。 AWS Glue Data Catalog で、ログが格納されている Amazon S3 Tables データベースを指すリソースリンクを作成します。 Amazon Redshift で、リソースリンクを参照する外部スキーマを作成します。 CREATE EXTERNAL SCHEMA <schema_name> FROM DATA CATALOG DATABASE '<resource_link_database>' IAM_ROLE '<iam_role_arn>'; 設定が完了すると、使い慣れた 2 部構成の表記法で過去のシステムテーブルデータをクエリできます。 SELECT * FROM <schema_name>.<table_name>; Amazon S3 Tables へのアクセスは読み取り専用のため、監査証跡の整合性は本質的に保たれます。 IAM ポリシーの例を含む詳細なセットアップ手順については、 S3 Tables と Data Catalog の統合の有効化 を参照してください。 データは Apache Iceberg 形式で保存される システムテーブルのデータは、オープンテーブル形式である Apache Iceberg で保存されるため、互換性のあるクエリエンジンを自由に選べます。可観測性や監査のデータを、すでに使っているツールでそのまま扱えます。 運用データは次のサービスで分析できます。 Amazon Redshift: S3 テーブルバケットを AWS Glue Data Catalog と統合したうえで、Amazon Redshift でリソースリンクを指す外部スキーマを作成し、保持されたテーブルをクエリします。 Amazon Athena: インフラのプロビジョニングなしで、過去のログに対してサーバーレスの SQL クエリを実行します。 AWS Glue: 運用データを基盤に、自動化されたデータ処理・変換ジョブを構築します。 Amazon EMR: 複雑なウェアハウス横断分析のために、Spark ベースの分析を大規模に実行します。 データは Amazon S3 Tables にオープンな Apache Iceberg 形式で保存されるため、Amazon Redshift、Amazon Athena、自然言語クエリ用の AI エージェントスキル、 Amazon SageMaker Unified Studio 、Iceberg 対応エンジン、ビジネスインテリジェンス (BI) ツール、可観測性システムなど、さまざまな手段でクエリできます。 コスト効率 Amazon Redshift から Amazon S3 Tables へのログ配信に追加費用はかかりません。料金が発生するのは、Amazon S3 Tables のストレージ、メンテナンス、および選択したエンジンでのデータのクエリに対してのみです。 ソリューションの概要 以下のシナリオでは、Amazon Redshift システムテーブルと Amazon S3 Tables の統合が、Amazon Redshift 環境全体でよくある運用・コンプライアンス・可観測性の課題をどのように解決するかを紹介します。また、本機能のために専用のスキル querying-aws-redshift を用意し、AWS MCP Server に組み込みました。これにより、Amazon S3 Tables から Amazon Redshift システムテーブルをクエリできます。 シナリオ 1: クエリの傾向を長期的に追跡する 数か月から数年分の SYS_QUERY_HISTORY データを保持しておけば、個々のクエリのパフォーマンスを長期間にわたって追跡できます。あるクエリの実行時間、キュー時間、リソース消費量を、日単位・週単位・月単位で比較できます。 パフォーマンスが劣化し始めた時期を正確に特定し、新しいスキーマ、データ量の急増、同時実行ワークロードの追加といった変更と関連付けられます。保持期間を延長することで、トラブルシューティングは事後対応から、先を見据えたデータドリブンな根本原因分析へと変わります。 シナリオ 2: 変更前後のワークロードへの影響を評価する 新しい ETL パイプライン、インスタンスタイプの変更、Workload Management (WLM) キューの調整、アドホッククエリを実行するアナリストチームの追加など、ワークロードの変更はいずれもシステムに影響します。問われるのはいつも、その変更がパフォーマンスにどう影響したかです。 Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、自信を持ってデータに基づいた意思決定ができます。 SYS_QUERY_HISTORY をクエリして、変更前の数週間と変更後の数週間で、実行時間、キューでの待機時間、同時実行スケーリングのイベントを比較します。2 週間前に新しいレポートワークロードを導入し、既存のクエリへの影響を把握したい場合、それを確認するためのデータはすでに揃っており、独自パイプラインは一切不要です。 シナリオ 3: 可観測性ダッシュボードを構築する システムテーブルのデータは Apache Iceberg で保存され、AWS Glue でカタログ化されます。つまり、Apache Iceberg を読み取れる可観測性ツールやビジネスインテリジェンス (BI) ツールから直接接続できます。経営層向けのレポートとして、ワークロードの分散傾向を Amazon Quick Sight で可視化できます。より深い分析や、運用データからの AI 主導のインサイト生成には、Amazon SageMaker Unified Studio を利用します。AWS のサービスにとどまらず、使い慣れたサードパーティの可観測性システムや BI ツールを接続して、クエリ量の追跡、接続パターンの監視、異常検知のアラート設定、あるいは Amazon Redshift の運用データとアプリケーションレベルのログの相関分析も行えます。 可観測性や監査のデータを、すでに使っているツールでそのまま活用できます。堅牢で構造化された運用データに、好みのツールから直接アクセスできます。 シナリオ 4: 季節性を踏まえてキャパシティを計画する ワークロードの需要は 1 年を通じて変動します。月次決算、四半期末のレポート、年間の計画サイクル、プロモーションイベントはいずれも予測可能な使用量のスパイクを生みますが、それはパターンを見て取れるだけの履歴データがあってこそです。 保持期間を延長すれば、複数のビジネスサイクルにまたがる使用状況の傾向を分析できます。キャパシティの上限に常に近づくのはいつかを特定し、需要が四半期ごとにどう変化するかを測定し、プロビジョニング済みのリソースが実際の使用量と見合っているかを検証できます。 シナリオ 5: コンプライアンスの監査証跡を維持する 規制対象の業界にとって、保持期間の延長は、整合性を標準で備えたフルマネージドの監査証跡をもたらします。 SYS_CONNECTION_LOG はすべての認証試行を記録します。 SYS_USERLOG はユーザーアカウントの変更を記録します。 SYS_QUERY_HISTORY はウェアハウスに対して実行されたすべてのクエリを記録します。 保持期間は、90 日、1 年、あるいは数年など、組織のデータ保持ポリシーに合わせて設定します。読み取り専用のアクセスポリシーにより、書き込み後のレコードが管理者を含む誰かによって改変されるのを防げます。 シナリオ 6: ウェアハウス群全体で運用の可観測性を一元化する 複数の Amazon Redshift ウェアハウスを運用している場合、運用データを統合的に把握できるメリットがあります。本機能は、組織構造に合わせて 2 つのデプロイパターンをサポートします。 ウェアハウスごとの個別テーブル: 各ウェアハウスが専用の Amazon S3 テーブルに書き込むため、コンプライアンス上の配慮が必要な環境向けに完全なデータ分離を実現します。複数のウェアハウスをまとめてクエリするには、 UNION 操作が必要です。 共有テーブル: 同じアカウント・同じ AWS リージョン内のウェアハウスが、共有された 1 組の Amazon S3 テーブルに書き込み、データは warehouse_name 列で区別されます。ウェアハウスで絞り込めば、クラスター横断の分析をすぐに行えます。 ベストプラクティス プライバシー上の理由でログの分離が必要なウェアハウスを特定し、それらには ウェアハウスごとの個別テーブル オプションを選択します。残りのウェアハウスには、管理を簡素化するために 共有テーブル (集約) オプションを使用します。 保持期間はコンプライアンス要件に合わせます。ストレージコストを抑えるため、コンプライアンス要件を満たす最小限の保持期間を設定します。 保持されたシステムテーブルをクエリする際は、 warehouse_account_id 、 warehouse_region_name 、 warehouse_namespace_arn 、 warehouse_name 、 s3_tables_ingestion_time などのメタデータ列で絞り込み、スキャン範囲を減らしてパフォーマンスを高めます。複数のウェアハウスにまたがる大量の履歴データをクエリする場合は、特に重要です。 監査証跡の整合性は、標準で備わる読み取り専用アクセスに任せます。保持期間や暗号化の設定は、Amazon S3 Tables の設定 API で管理します。 暗号化の方針は早い段階で計画します。設定後の変更には統合の再作成が必要になるため、暗号化キーはセットアップ時に慎重に選びます。将来的にウェアハウスを集約する見込みがあるなら、最初から共有の AWS KMS キーを選んでおきます。 まとめ Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、独自の ETL パイプラインをフルマネージドのソリューションに置き換え、Amazon Redshift の運用データを保持します。Apache Iceberg ベースのストレージへの自動保存、オープン形式でのクエリ、標準で備わる監査整合性により、数か月から数年分の可観測性データをフルマネージドで得られます。 AWS Management Console 、 AWS Command Line Interface (AWS CLI) 、 AWS SDK から有効にできます。 詳しくは、 Amazon Redshift システムテーブルのドキュメント を参照してください。 著者について Nidhi Nayak Nidhi は、AWS のシニアテクニカルアカウントマネージャーです。エンタープライズのお客様がスケーラブルで高性能なクラウドアプリケーションを構築し、クラウド運用を最適化できるよう支援しています。データ分析の分野で 10 年以上の経験を持ち、現在は Amazon Redshift と、Redshift への生成 AI の統合に注力しています。 Raza Hafeez Raza は、Amazon Redshift のシニアプロダクトマネージャー (テクニカル) です。エンタープライズのデータウェアハウスの構築と最適化に 15 年以上携わり、あらゆる規模のお客様にとってクラウド分析を使いやすく、コスト効率の高いものにすることに情熱を注いでいます。 Shubham Purwar Shubham は、AWS の Analytics スペシャリストソリューションアーキテクトです。AWS プラットフォーム上でスケーラブルかつ安全で高性能な分析ソリューションを設計・実装し、お客様がデータの潜在能力を最大限に引き出せるよう支援しています。AWS の分析サービスに関する深い専門知識を活かし、お客様と協力して個別のビジネス要件を明らかにし、具体的なインサイトをもたらしてビジネスの成長を促すカスタマイズされたソリューションを構築しています。プライベートでは、家族と過ごしたり世界中を旅行したりするのが好きです。 Amrita Singh Amrita は、米国ソルトレイクシティを拠点とする AWS のシニアテクニカルアカウントマネージャーです。Amazon Redshift を専門とし、エンタープライズのお客様がデータウェアハウス環境をパフォーマンス、スケーラビリティ、コスト効率の面で最適化できるよう支援しています。お客様と直接連携してクラウド活用のガイダンスや技術支援を提供し、AWS のサービスによって柔軟性、スケール、耐障害性を高められるよう手助けしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。