Kiro とともに医療情報システムのガイドライン遵守開発に挑む

Kiro 好きの Solutions Architect の吉村です。普段はヘルスケア業界のお客様の技術支援に加えて、業界問わず Developer Experience に関するご支援をさせていただいております。

本記事では、医療情報システム開発で避けて通れない数多くの業界ガイドラインに対して、Kiro を医療情報システム開発をよく理解したチームの一員へと育て上げ、一緒に立ち向かうというアプローチをご紹介します。本アプローチは、第 30 回日本医療情報学会春季学術大会の AWS ブースや AWS Summit Japan 2026 のヘルスケアブースでのデモ展示で、来場者の皆様と議論し、好意的なフィードバックをいただいたものをベースにしています。

はじめに

医療情報システムの開発には、医療情報システムの安全管理に関するガイドライン 第 7.0 版（いわゆる 3 省 2 ガイドラインの 1 つで、厚生労働省が定めるもの。以降「医療情報ガイドライン」）や、電子カルテの標準仕様、公共 SaaS 要件 (GCAS ガイド) など、参照するべき業界ガイドラインが数多く存在します。医療領域で AI を使おうとする多くの開発現場が「AI 駆動開発でスピードを上げたいけど、大量の業界ガイドラインをどう扱えばいいのか」という悩みに直面します。

今回のアプローチは、AI 活用のベストプラクティスを組み合わせた実験的なもので、皆さんの組織やプロジェクトに合わせて取捨選択・カスタマイズして使うことを前提とします。本記事では Kiro の Agent Skills と Agent Steering で具体化しますが、本質は動的に読み込める知識と開発ルールを与えることにあります。そのため Claude Code など他のコーディングエージェントでも応用でき、皆さんの普段の開発に後付けで組み込めます。

医療情報システム開発で AI 駆動開発がぶつかる壁

規制やガイドラインの多い医療ドメインでは、AI 駆動開発にまつわる様々なアンチパターンに遭遇することがしばしばあります。具体的なアプローチに入る前に、まずは私たちがぶつかる壁を整理します。

AI 駆動開発における課題

大規模言語モデル (LLM) には、コンテキストウィンドウ（エージェントが一連の作業の中で参照できる情報の枠）があります。ここにはシステムへの指示、会話の履歴、読み込んだファイル、ツールの実行結果などが収まり、その容量はトークン量で決まる有限の予算のようなものです。コンテキストウィンドウが大きくなればそれだけ多くの情報を投げ込めて、より良い結果が得られると考えがちですが、実際はそう単純ではありません。入力が長くなるほどパフォーマンスが低下することが、近年さまざまな研究で報告されています。

Chroma が 2025 年に公開した技術レポート 「Context Rot: How Increasing Input Tokens Impacts LLM Performance」で、入力長が増えると単純なタスクでも性能が大きく変動すると報告しています。

We observe that model performance varies significantly as input length changes, even on simple tasks.

Nelson F. Liu 氏らが 2023 年に発表した研究 「Lost in the Middle: How Language Models Use Long Contexts」では、関連情報が長いコンテキストの中間に置かれると見落とされやすい傾向が報告されています。

significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models.

Philippe Laban 氏らが 2025 年に発表した研究 「LLMs Get Lost In Multi-Turn Conversation」は、指示が曖昧なまま会話がマルチターン化すると、トップクラスのモデルでも性能が低下する。一度誤った仮定を置くと、その後もそれに固執して立て直せなくなる傾向があると報告しています。

when LLMs take a wrong turn in a conversation, they get lost and do not recover

クラウド上のワークロードを設計・運用するためのベストプラクティス集である AWS Well-Architected Framework の Agentic AI Lens でも、今のタスクに必要なものだけを組み立て、残りは圧縮・要約することをベストプラクティスとして挙げ、会話履歴やツール定義を毎回すべて詰め込むことをアンチパターンとしています。

これらは、曖昧な指示が AI を不要な仮定へと突き進ませるという現場の実感とも重なります。さらに不要・冗長な情報を詰め込めば、いわゆる AI slop と呼ばれる質の低い出力やハルシネーションを招きます。結果として、指示の質によって成果物の品質に差が生まれます。

医療情報システムにおける課題

こうした一般的な問題に、医療領域ではドメイン固有の事情が重なります。まず、参照するべき業界ガイドラインが大量にあります。医療情報ガイドラインだけを見ても、概説編・経営管理編・企画管理編・システム運用編・保守委託機関編の 5 編から成り、全体で 160 ページを超えます。医療情報ガイドライン全体の概要は、AWS ブログ「医療情報ガイドラインをクラウド上で実践する -概要編-」でも解説しています。さらに標準仕様に準拠した電子カルテの開発では、GCAS ガイドや電子カルテの標準仕様書の遵守が必要で、Web ページや大量の PDF・エクセルなど形式もさまざまです。これらを人間がすべて理解して AI に的確に指示するのは、簡単ではありません。

ここで 1 つ皆さんにクイズです。Kiro IDE は添付したドキュメントをネイティブのドキュメントブロックとして読み込むことができますが、「医療情報ガイドラインのうち、システム運用編という 1 編だけを添付したら、Claude Opus 4.8 の 100 万トークンのコンテキストは何割くらい埋まるでしょうか？」

Claude Opus 4.8 で医療情報ガイドラインのシステム運用編を添付した直後のコンテキスト消費量

実際に Claude Opus 4.8 で試すと、この 1 編だけで対話開始時点のコンテキストの約 29% が消費されました。全 5 編ではさらに膨らみ、加えて開発標準や MCP も読み込まれると、やり取りできる余地はますます狭まります。コンテキスト上限に近づくと、多くのコーディングエージェントでは内容が自動的に圧縮 (コンパクション) されます。このことからも、ドキュメントを「とにかく全部 AI に渡す」のは筋が悪く、「必要なときに、必要な情報を、必要な分だけ」渡すべきです。

そして、最終的な妥当性を担保し、責任を持つのは人間です。ドキュメントを与えずに指示を出す場合、その人の理解度がそのまま AI への指示の正確さと出力の精度を左右します。結果として、関わるロールや習熟度によって、指示や成果物の品質に差が生まれやすくなります。

医療情報システムの AI 駆動開発が直面する課題

Kiro をチームの一員に育て上げる

ここまで見てきた課題に立ち向かうために、Kiro を「医療情報システム開発をよく理解したチームの一員」に育て上げます。医療情報システム開発に必要な知識と組織の開発の進め方を少しずつ授けていきます。

Kiro とは

Kiro は、AI にコードを書かせるだけの段階を越えて、エージェントと協働してソフトウェアを設計・実装する、agentic engineering のための開発環境です。プロンプトから実行可能な仕様 (Spec) を起こす仕様駆動開発や、複数のエージェントによる並行作業などを特徴とし、今回活用する Agent Skills・Agent Steering のほか、MCP・マルチモーダル入力・ドキュメント添付といった機能を備えています。

アプローチの全体像

本記事では、[企画] → [準備] → [開発] → [改善] という 4 つのフェーズに沿って、ソフトウェア開発ライフサイクル (SDLC) 全体を通してこのアプローチを見ていきます。

• [企画] Kiro と壁打ちしてアイデアを言語化
• [準備] ガイドラインの知識を Agent Skills として与え、コンテキストを構築
• [準備] 開発標準やルールを Agent Steering として与え、ハーネスを構築
• [開発] 要件定義から設計・実装・テスト・デプロイなど、SDLC 全体を Kiro と一緒に推進
• [改善] 開発で見えた学びやプロダクトの成熟度に応じて、知識やハーネスを洗練

企画・準備・開発・改善の 4 フェーズと、各フェーズ共通の制御ループ

この 4 つのフェーズに共通して、人間と AI が交互に手を動かしながら、以下の制御ループを繰り返します。

1. 人間が AI にタスクを依頼
2. AI が計画を作成
3. 人間がレビュー
4. AI が計画を見直し
5. 人間が計画を承認
6. AI が計画を実行
7. 人間が AI の成果物を検証

このループを各フェーズで回すことで、Kiro に丸投げするのではなく、人間が意思決定権と監督責任を持ち続けます。

しかし、人間の意図は曖昧性をはらんでいます。出発点が曖昧になると AI は不要な仮定を置き、望んでいない方向へ進み始めます。この曖昧性をできる限り排除するために、Kiro が作成する計画の中に、曖昧な部分についての逆質問を含めさせます。曖昧なまま進めず、不明点を [Question] として挙げさせ、人間が [Answer] で意図を伝え、独自の判断で先に進ませません。計画に合意してから実行に移すことで、曖昧な指示による手戻りを未然に防げます。

AI に逆質問させるプロンプト例。不明点を [Question] で挙げさせ、人間が [Answer] で意図を伝える

それでは、各フェーズを具体的に見ていきます。

[企画] Kiro と壁打ちして構想を固める

これから作るものの構想を、Kiro と壁打ちしながら言語化します。漠然としたアイデアを整理し、ビジネスチームとエンジニアチームが同じ言葉で議論できる共通認識をつくります。

このとき活躍するのが、Kiro のマルチモーダル入力です。ホワイトボードのラフな構成図や手書きのスケッチ、画面イメージなど、言語化しにくいものを画像で渡し、Kiro と対話しながらドキュメントへ落とし込めます。

あわせて、構想の実現可能性や業界の動向も Kiro と一緒に調べ、技術的な選択肢や懸念点を洗い出しながら具体化します。ここでも制御ループが効き、計画段階での逆質問で曖昧な構想の穴を早めに埋められます。

[準備] ガイドラインの知識を Agent Skills として与える

ここからが、Kiro へ開発に必要なコンテキストを与えるフェーズです。

まずは、医療情報システム開発に必要なガイドラインの知識を Agent Skills として用意します。スキルは動的に読み込まれるので、Kiro は常に全文を抱え込むのではなく、そのとき必要な知識だけを読み込んで参照します。大量のガイドラインで最初からコンテキストを圧迫することなく、「必要なときに、必要な情報を、必要な分だけ」読み込みます。

スキルの作り方はシンプルで、Kiro 自身にスキルを作らせます。医療情報ガイドラインのような PDF はドキュメントとして直接添付し、GCAS ガイドのように Web で公開されている情報はビルトインの web_fetch ツールでコンテキストに取り込みます。あとは全体像で触れた制御ループに沿って、どんな粒度で分割すべきかを Kiro に計画させ、曖昧な部分は質問させて詰めたうえで、計画を承認してからスキルを生成、成果物を人間がレビューします。

たとえば、ネットワークや認証、データ管理、セキュリティといったトピックごとのスキルに分割し、SKILL.md にどんな場面で参照すべきかという説明を、references フォルダに詳細な要件をまとめた参照ファイルを配置します。

[準備] 開発標準を Agent Steering として与える

スキルで知識を渡したら、次は開発の進め方を Kiro に教えます。Agent Steering は、ワークスペースの標準やアーキテクチャ、コーディング規約といった前提を Markdown ファイルに定義しておくと、セッションのたびにユーザーが指示しなくても自動的にコンテキストへ読み込まれる仕組みです。プロダクト概要 (product.md)、技術スタック (tech.md)、プロジェクト構造 (structure.md) といった基盤ファイルや、コーディング規約などの独自ファイルを用意できます。

ここでハーネスという考え方を取り入れます。ハーネスとは、AI を信頼できる開発の担い手にするために、その周りに用意する仕組みです。どれだけ高性能なモデルでも、それ単体で常に期待どおりに動くとは限りません。適切なコンテキストを渡し、進め方や守るべきルールを与え、振る舞いを制御し、出力を検証する。こうした足場を整えてはじめて、AI に開発の一員として安心して任せられるようになります。

ハーネスは単一の機能ではなく、複数の要素の組み合わせです。たとえば、知識を与える Agent Skills、開発の進め方や規約を効かせる Agent Steering、外部のツールやデータへ安全につなぐ MCP、成果物を機械的に検査するテストや静的解析などです。Agent Steering はこれらのピースの一つです。

最初から完璧に作り込む必要はありません。小さく始めて、開発を回しながら見えてきた学びを少しずつ反映したり、プロジェクトの成熟度に合わせて洗練させていくのが現実的です。

たとえば、すでに組織の開発標準や設計方針がドキュメント化されているなら、それらを入力に Kiro と一緒に Agent Steering へ落とし込めます。まだなければ、制御ループの中で Kiro に組織の開発プロセスのあるべき姿を深掘りさせ、一緒に形にしていくこともできます。これらをプロジェクトのハーネスの出発点にすることができます。

ここまで見てきた Agent Skills も Agent Steering も、その実体は Markdown ファイルです。そのため、ソースコードと同じように Git などのバージョン管理ツールで変更を追跡でき、GitHub などを通じてプロジェクトのメンバー全員へ配布できます。こうして育てた Kiro のコンテキストとハーネスは、チームの共有資産として扱えます。

[開発] 整えた土台の上で、Kiro とともに開発する

準備フェーズまで終えると、実は開発フェーズで新しくお伝えすることは、それほど多くありません。ここまで整えてきたコンテキストとハーネス、そして制御ループの上で、皆さんの組織の開発プロセスと設計手法に沿って開発を進めるだけです。

ただし、これは従来どおりの開発を行うだけではありません。Kiro とともに AI ネイティブな開発へとシフトします。人間は実現したい意図を Kiro に伝え、制御ループの中でその意図を一緒に洗練し、コードやドキュメントを書く作業そのものは Kiro に任せます。そのうえで人間は、生成された成果物をレビューし、最終的な意思決定と監督責任を担う立ち回りへと移ります。

開発の進め方そのものは、組織やプロジェクトによってさまざまです。たとえば、チームのための AI ネイティブな開発方法論である AI-DLC を実践するために、OSS で公開されている補助ツール AI-DLC Workflow をベースにしたとします。AI-DLC は Inception・Construction・Operations の 3 つのフェーズからなり、クロスファンクショナルなチームがモブワークで AI と協働し、AI の提案をその場で検証しながら進めるのが特徴です。

要件定義のフェーズ (Inception) では、ユーザーに届けたい価値を起点にユーザーストーリーや受け入れ基準を定義し、並行開発できる単位へとタスクを分解します。

設計・実装のフェーズ (Construction) では、詳細設計から実装、テストへと進めます。このとき Kiro は、準備フェーズで与えたガイドラインの知識や開発標準を参照しながら、成果物を生成します。これらの成果物を人間が検証していきます。

ただし、AI-DLC Workflow はあくまで一例です。重要なのは、皆さんの組織固有の開発プロセスそのものを Kiro に教え、AI ネイティブなプロセスへと変革させていくことです。

AI-DLC については「AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築」をご参照ください。

[改善] ハーネスを育て続ける

ここまで構築してきたコンテキストとハーネスは、一度作って終わりではありません。開発で得た学びやプロダクトの成熟度に応じて、コンテキストとハーネスの 2 つの面から育て続けます。

まず、Kiro に与えた知識（コンテキスト）を最新に保ちます。医療情報ガイドラインのように、規制やガイドラインそのものが改定されることもあります。こうしたとき、改定版を読み込ませて変更点を整理し、該当する Agent Skills を更新すれば、最新の内容に追従し続けられます。膨大な改定内容の読み込みと差分の整理を、Kiro は人間よりはるかに高速にこなせます。これが、規制やガイドラインの多い医療ドメインで、AI ネイティブな開発を行う意義でもあります。

あわせて、開発を支える仕組み（ハーネス）も強化します。たとえば SAST (静的解析) やテストを整備し、ガイドライン遵守・セキュリティ・品質の観点を継続的に検査できるようにします。さらに Kiro の Agent Hooks を使えば、ファイルの保存やタスクの完了といったイベントをきっかけに、これらの検査やレビューを自動で実行できます。手作業の抜け漏れやセキュリティ上の見落としを、仕組みで防げるようになります。

こうしてコンテキストとハーネスが育つほど、Kiro は医療情報システム開発を理解したチームの一員として、ますます頼れる存在になっていきます。

このアプローチの何が嬉しいか

ここまで、Kiro をチームの一員に育て上げる流れを見てきました。このアプローチがもたらす効果を整理します。

1 つ目は、開発に関わる全ロールが「同じ前提を備えた Kiro」と協働できることです。医療情報システム開発に必要な知識も開発標準も Kiro 側に持たせているため、それらを参照するのは人間ではなく Kiro です。企画担当も設計者も実装者も QA も、同じ知識とハーネスを備えた Kiro を相棒にできます。これにより、人間が的確な指示を出す難しさや曖昧さを、組織全体で減らせます。

2 つ目は、いま使っている開発プロセスに後付けできることです。このアプローチの本質である Agent Skills と Agent Steering は Markdown ファイルにすぎません。そのため、既存のワークフローやツールチェーンを置き換える必要はなく、非侵襲的に組み込めます。ゼロから作り直さなくてよいので、導入のハードルも低いです。

そして 3 つ目は、組織全体の AI 活用のバーを引き上げられることです。こうして育てた Kiro は、組織全体で共有できます。AI はあくまで人の力を増幅する Amplifier であり、担当者ごとの個人差そのものがなくなるわけではありません。ただ、知識もハーネスもない素の状態に比べれば、どの役割の人もより良い結果にたどり着きやすくなります。

まとめ

本記事では、医療情報システム開発で避けて通れない数多くの業界ガイドラインに対して、Kiro をチームの一員に育て上げて一緒に立ち向かうアプローチをご紹介しました。大量の業界ガイドラインを抱え込んでコンテキストを圧迫するのではなく、ガイドラインの知識を Agent Skills として与え、開発標準を Agent Steering として最初のハーネスを組み込み、制御ループの中で人間が意思決定権と監督責任を持ちながら Kiro と協働する。その土台作りと洗練を重ねることが、このアプローチの核です。

冒頭でも触れたとおり、このアプローチは確立された方法ではなく、AI 活用のベストプラクティスを組み合わせた実験的なものです。だからこそ、皆さんの組織やプロジェクトに合わせて取捨選択し、カスタマイズしていただければと思います。本質は動的に読み込める知識と開発ルールを与えることなので、いま使っているコーディングエージェントや開発プロセスに後付けで試せます。まずは小さなスキルやステアリングを 1 つ作るところから、Kiro と一緒に始めてみてください。

皆さんの開発現場で Kiro が頼れるチームの一員になることを願っています。そしてより良い医療情報システムをより早く提供できる未来を信じています。

著者について