はじめに 先に、ログの用語を整理します そもそもログとは 2 つを並べると エンジンごとの呼び名 RDS のレプリケーションは 2 種類あります 同期レプリケーション（マルチ AZ のスタンバイ宛） 実装はエンジンによって異なります スタンバイが読み取りに使えない理由 非同期レプリケーション（リードレプリカ） リードレプリカはどちらのログを使うのか まとめると、レプリケーションには 3 階層あります Aurora はアーキテクチャが根本的に異なります ① Writer → ストレージ（永続化） ② Writer → Reader（物理レプリケーション） ③ Reader → ストレージ（読み取…

航空業界では、散在するデータの横断的な活用が長年の課題でした。本ブログでは、 Amazon S3 を中心としたデータレイクに航空データを集約し、Amazon Bedrock AgentCore と Amazon Bedrock Knowledge Bases で横断的に AI 検索できる 航空オペレーション基盤 を紹介します。この基盤の上に業務アプリケーションを載せて具体的な課題を解決する例として、 ターンアラウンド管理 （フライトの地上折り返し作業の可視化・管理ツール）を紹介します。 また、本ソリューションは Kiro （AI 搭載の IDE）を活用し、自然言語による仕様定義からコード実装までを一貫して行う「スペック駆動開発」で構築しています。要件を自然言語で整理すれば、ここで紹介する規模のソリューションを開発できることも合わせてお伝えします。 注： 本ソリューションで使用している航空データ（フライトスケジュール、整備マニュアル、乗客情報など）はすべて架空のデモデータです。実在の航空会社・便名・人物とは一切関係ありません。 なぜ作ったのか 本ソリューションは、以下の問いに答えるために構築したデモソリューションです。 「航空会社が保有する膨大で多様なデータを、 AWS の AI ・データサービスで統合し、現場の意思決定を加速できるか？」 航空会社は日々、フライトスケジュール、フライトデータ、整備マニュアル、安全報告書、作業員音声記録、ケータリング在庫、乗客情報など、膨大なデータを生成しています。しかしこれらは業務システムごとにバラバラに管理されており、横断的な分析には人手と時間がかかります。 現場がよく直面する課題として、たとえば以下のようなものがあります。 情報がバラバラに散らばっている — 「この機材の整備履歴と異常を突き合わせたい」と思っても、 3 つも 4 つもシステムを開いて手作業で確認するしかない 蓄積されたデータが業務改善に活かされていない — 日々生成されるフライトデータ、作業記録は膨大ですが、分析や意思決定に活用する仕組みが追いついておらず、経験と勘に頼った判断が続いている ベテランの知識が共有されない — 整備マニュアルの PDF 、安全報告書、経験に基づくノウハウ。キーワード検索では見つからず「あの人に聞くしかない」状況 これらの課題に対し、 AWS が提案するのは 「聞けば、必要な情報が集まり、状況が分かる」 航空オペレーション基盤です。各システムのデータをデータレイクに集約し、 AI が横断的に検索・統合して回答する仕組みで解決します。 ソリューションの全体像 本ソリューションは 2 つの層で構成されています。 データレイク（基盤層） — 38 GB ・約 29 万ファイルの航空データ全体に、自然言語で質問するだけで答えが返ってくる AI 検索基盤 ターンアラウンド管理（活用層の一例） — データレイク基盤の上に構築した、フライトの地上作業を可視化・管理する課題解決ツール（このようなツールを業務ごとに追加できる構成です） 両層は AI の検索基盤を共有しており、ターンアラウンドの作業画面から画面を切り替えることなく、整備マニュアルや過去のフライトデータに自然言語で質問できます。 データレイク — 「聞くだけ」で全データから答えが返る フライトスケジュール、整備マニュアル、安全報告書、フライトデータ、作業員の音声記録。これまで別々のシステムに散在していた航空データを、 AI が横断検索できるようにしました。 使い方は簡単です。画面右側のチャット欄に、普段使う言葉で質問を入力するだけ。 AI が関連する複数のデータソースから情報を収集・統合し、回答を生成します。キーワードの完全一致ではなく「意味」で検索するため、マニュアルの表現が少し違っていても関連情報を見つけ出します。 従来は複数のシステムを手動で開いて突き合わせに 30 分以上かかっていた作業が、 AI への一言の質問で数秒に短縮されます。しかも、人が見落としがちな関連情報も AI が自動的に引き出します。 AI 分析パネル。「このデータをどう活用できるか？」と聞くだけで、 AI がターンアラウンド最適化、整備計画の高度化、安全分析など具体的な活用シナリオを提案。左側のエクスプローラーでデータを閲覧しながら AI に相談できる統合画面。 データの全体像を把握するダッシュボードも備えています。「そもそもどんなデータが、どれだけあるのか」を可視化することで、分析の出発点を明確にします。データの偏りやカバレッジの不足も一目で発見できます。 データカタログダッシュボード。カテゴリ別のデータ量・ファイル数・最終更新日を一覧表示。「特定カテゴリのデータが最大」「最近更新されたファイル」など、データの健全性を即座に確認できる。 地図・フライトデータ・音声 — 多様なデータをそのまま活用 航空データは構造が多種多様です。テキストだけでなく、航路データ（地図表示）、フライトレコーダー、作業音声（録音ファイル）を、それぞれ最適な形式でプレビュー・活用できます。わざわざ専用ソフトを開く必要がなく、ブラウザ上で即座に確認できることが運用効率に直結します。 航路データの地図表示。特定便の飛行ルートが地図上に自動描画される。航路計画と実績の比較や、空域の可視化に活用。 フライトレコーダーの構造表示。姿勢・エンジン・環境・位置の各データが 2,880 ポイントで記録。専用ソフト不要でデータの中身を即確認。 作業音声の再生画面。ケータリング搭載作業の録音をブラウザ内で直接再生でき、 AI による文字起こしと要約もセット表示。ベテランが口頭で伝える作業ノウハウを、テキスト化して組織の共有知にする仕組み。 ターンアラウンド管理 — データ活用による課題解決ツールの一例 データレイク基盤の上に構築した具体的な課題解決ツールとして、ターンアラウンド管理（フライトの到着から出発までの地上作業の可視化・管理）を紹介します。 飛行機が到着してから次に出発するまで、わずか 45 〜 90 分。その間に清掃、給油、ケータリング搭載、手荷物積み降ろし、機体点検など多数の作業を並行して完了させなければなりません。本デモでは仮に以下の 8 つの作業を定義していますが、実際の運用では乗務員ブリーフィングや機用品補充なども加わります。必要な作業が変わった際にも柔軟に追加や入れ替えができる設計にしています。 口頭報告を待たなくても全タスクの状態が即座にわかり、遅延の兆候を早期に検知できます。 45 分のターンアラウンドで 5 分の遅延発見が早まるだけで、定時出発率への影響は大きく変わります。 フライト一覧 — 全便の状況を一目で把握 本日の運航便を一覧表示し、各便のターンアラウンド進捗を色分けで即座に確認できます。「どの便が問題を抱えているか」を管理者が瞬時に判断し、リソースを再配分するための全体俯瞰画面です。 3D 地球儀モードでは飛行中の便の位置がリアルタイムに更新され、全体のオペレーション状況を直感的に把握できます。 フライト一覧。各便の進捗が色分け表示され、遅延が発生している便を即座に特定できる。 3D 地球儀モード。飛行中の便は赤色アイコンで位置がリアルタイム更新。運航全体の俯瞰に。 フライト詳細 — 1 便の全情報を集約 便を選択すると、その便に関する全ての情報が一画面に集約されます。 8 タスクの進捗バー、機材情報、出発・到着時刻、乗客数。複数画面を行き来する必要がなく、「この便は今どういう状態か」が 1 クリックで完全に把握できます。 フライト詳細画面。 8 タスクの進捗バー・機材情報・乗客数が一画面に統合され、便の全体像を即座に把握できる。 タスク管理 — 現場からリアルタイムに報告 作業員が無線機やスマートフォンから「作業開始」「作業完了」を 1 タップで送信するか、現場の無線通信内容から AI がステータスを自動判定して、管理画面にリアルタイムで反映されます。 従来の口頭報告やハンドサインに頼る仕組みでは、「報告を受けた時にはもう遅い」ことが多発していました。デジタル入力にすることで、報告の遅延ゼロ・記録の自動蓄積を同時に実現します。蓄積されたデータは過去分析に活用でき、「どのタスクがどの空港でボトルネックになっているか」を定量的に把握できるようになります。 タスク管理の初期状態。 8 タスクが全て「未着手」。ここからリアルタイムに状態が変化。 作業進行中。一部タスクが「進行中」に変わり、進捗バーで可視化される。 無線機から受信を開始すると、文字起こしをしながらステータスコマンドを監視。 無線通信が終了すると、録音データとともに、文字起こしと要約を保存し、音声からタスクのステータスを自動変更。 スマートフォンからもタスク入力が可能。専用デバイスがなくても、既存のスマートフォンで即座に運用開始できる。導入コストの低さも重要なポイント。 完了結果 — 作業実績の自動記録と分析 全タスク完了後、各タスクの所要時間・音声記録の文字起こし・ AI 要約が自動的に生成されます。手書き報告書の作成が不要になり、作業記録は即座に検索・分析可能な形で蓄積されます。「何が報告されたか」「どのタスクで問題があったか」を定量的に振り返れるようになります。 作業音声の文字起こし結果を自動表示。 AI が文字起こしから要約を自動生成。 タスク別の作業報告をテキストで一覧確認。 フライトツイン 3D — 巡航中の機体のデータを「見て」判断する 飛行中の航空機のフライトデータを 3D でリアルタイムに可視化し、フライトレコーダーのデータと連動させます。 PFD（計器表示）、エンジン状態、健全度スコアがリアルタイムに更新されます。 エンジン温度の偏差や N1 回転数の左右非対称など、数値だけでは気づきにくい異常の兆候を視覚的に捉えられます。「見ていて面白い」だけでなく、故障予兆の早期発見という実用的な価値があります。整備部門との情報共有も、 3D 画面を共有するだけで直感的に行えます。 フライトツイン 3D 。巡航中の機体をリアルタイムに可視化。 PFD（速度・高度・姿勢）とエンジン計器が連動し、機体の健全度スコアも常時表示。 7 つの表示レイヤー（3D 地形、飛行経路、 PFD 、エンジン、健全度、環境、方位）を目的に応じてオン・オフ可能。 フライトレコーダー分析 — フライトデータを AI が読み解く エンジン温度、振動、油圧などのフライトデータを時系列グラフで表示し、 AI が異常値の傾向を自動判定します。過去のフライトとの比較も可能です。 ベテラン整備士が経験に基づいて「この数値の傾向は気になる」と判断していたプロセスを、 AI が 24 時間自動的に実行します。属人的な判断を組織的な仕組みに変え、見落としリスクを低減します。 フライトデータの時系列表示。各パラメータの推移を一画面で確認。 AI による分析結果。エンジン健全度スコアや異常傾向を自動判定し、注意が必要な箇所をハイライト。 ケータリング搭載管理 — 搭載計画から在庫管理まで一元化 機内食の搭載計画と在庫管理を統合しています。「どの機材のどのギャレーに、どのカートを搭載するか」を視覚的に管理できます。在庫状況・販売実績・需要予測まで一画面で確認でき、欠品リスクの早期検知と発注判断を支援します。 ケータリング搭載の遅延はターンアラウンド全体に波及します。搭載計画を事前に最適化し、在庫不足を予測段階で検知することで、当日の手戻りを防ぎます。また、エアライン別のデータ分離により、外航受託便でも正確な搭載管理が可能です。 品目別の搭載数と在庫引き当て。欠品リスクを事前に検知。 ケータリング管理の概要。搭載計画の全体像を把握。 機材別カート配置図。搭載位置を視覚的に指示。 乗客情報 — サービス品質の事前準備 搭乗予定の乗客情報を事前に把握し、サービス品質の準備に活用できます。上級会員の比率が高い便では追加の対応準備が必要になりますし、販売チャネルの偏りは今後のマーケティング施策にも活きるデータです。 会員ランク別構成。上級会員比率を事前把握し、サービス準備の判断材料に。 販売チャネル別構成。予約経路の傾向分析に活用。 分析ダッシュボード — 過去データから改善ポイントを発見 蓄積されたターンアラウンドデータを集計し、「どのタスクが遅れやすいか」「どの空港で遅延が多いか」「時間帯による傾向はあるか」といった分析が行えます。 感覚的だった改善活動が、データに基づく定量的な PDCA サイクルになります。「特定空港の給油は午後に遅延しがち」「特定機材の清掃は他機材より 10 分長い」といった具体的な知見が得られ、人員配置やプロセス改善の根拠になります。 ターンアラウンド分析ダッシュボード。タスク別の平均所要時間・遅延傾向・空港別パフォーマンスを可視化し、改善すべきポイントを明確にする。 AWS アーキテクチャ ここからは、本ソリューションを支える AWS の技術構成について解説します。 データレイクの構成 データレイクの AWS 構成。 CloudFront → ALB → ECS Fargate（Private Subnets）。 S3 Files Volume をマウントし、 VPC Endpoint 経由で AgentCore Gateway → Knowledge Base → Claude に接続。 EventBridge → SQS → Lambda → DynamoDB でカタログ自動同期。 S3 共有バケットに格納された航空データ（38 GB / 29 万ファイル）を Amazon Bedrock Knowledge Bases でベクトルインデックス化し、 Amazon Bedrock AgentCore Gateway 経由で統合的にアクセスします。 主要コンポーネント： Amazon Bedrock AgentCore Gateway — RAG 検索の統合エンドポイント（IAM SigV4 認証、複数システムから共有利用） Amazon Bedrock Knowledge Bases — S3 上の航空データに対するセマンティック検索 Amazon S3 Vectors — サーバーレスベクトルストア（管理不要、低コスト） Amazon Titan Embed V2 — 埋め込みモデル（1,024 次元） Amazon EventBridge — S3 オブジェクト変更のリアルタイム検知 Amazon SQS — デバウンス付きバッファ（5 分ウィンドウで変更を集約） AWS Lambda — カタログインデクサー、 KB 同期、統計集計（6 関数） Amazon DynamoDB — カタログメタデータ・統計情報のサーバーレス管理 カタログ自動同期の仕組み S3 オブジェクト変更 (PUT / DELETE) → EventBridge ルール（リアルタイム検知） → SQS キュー（デバウンス: 5 分ウィンドウで集約） → Lambda（カタログインデクサー） → DynamoDB 更新 → Knowledge Base インジェスション（ベクトル再構築） S3 にデータを置くだけで AI 検索インデックスが自動更新される仕組みです。 SQS の 5 分デバウンスで細かな変更を集約し、 Lambda 起動回数とコストを最適化しています。 ターンアラウンド管理の構成 ターンアラウンド管理の AWS 構成。 ECS Fargate 上のフロントエンド（React + Three.js + MapLibre）とバックエンド（Express.js + WebSocket）が、 AgentCore Gateway 、 Transcribe 、 Location Service 、 S3 Files と連携。 ユーザー（ブラウザ） → CloudFront → ALB → ECS Fargate (フロントエンド: React + Three.js + MapLibre) → ECS Fargate (バックエンド: Express.js + WebSocket) ├→ AgentCore Gateway (SigV4) → KB → Claude [AI 分析] ├→ Amazon Transcribe (WebSocket) [音声文字起こし] ├→ Amazon Location Service (API Key) [地図・航路描画] └→ Amazon S3 + S3 Files (/mnt/s3) [データストレージ] └→ エフェメラルキャッシュ (50 GB) [高速読み込み] 主要コンポーネント： Amazon Bedrock (Claude Sonnet 4 / Claude 3.5 Haiku) — AI 分析・要約生成 Amazon Transcribe — 作業員音声のリアルタイム WebSocket 文字起こし Amazon Location Service — 空港マップ・航路可視化（API Key 方式） Amazon ECS on AWS Fargate — バックエンド・フロントエンドのコンテナ実行 Amazon S3 + S3 Files — 38 GB / 29 万ファイルの共有ストレージ（NFS マウント） Amazon Polly — デモ音声生成（Neural ボイス、デプロイ時バッチ処理） AWS Cost Explorer — システム別コスト可視化 Kiro によるスペック駆動開発 本ソリューションは、 AWS が提供する AI 搭載 IDE Kiro を活用して構築しています。 Kiro のスペック駆動開発では、開発者が自然言語で要件を定義すると、 AI が設計・タスク分解・コード実装までを一貫して支援します。 自然言語で要件を記述（requirements.md） → Kiro が技術設計を提案（design.md） → タスクリストを自動生成（tasks.md） → タスクに沿ってコードを実装 → 受入基準に基づく検証 本プロジェクトでは、 12 のサブシステムにわたる 79 個の仕様ファイルを Kiro のスペックとして管理しています。 24 の要件を 9 つのフェーズに分割して段階的に実装しました。要件を自然言語で整理すれば、ここで紹介した規模のソリューションを Kiro で開発できます。 まとめ 本ソリューションは、航空オペレーションが抱える「データのサイロ化」「作業進捗の不可視性」「暗黙知の属人化」という 3 つの課題に対して、 AWS サービスの組み合わせでどこまで解決できるかを示すリファレンス実装です。 散在するデータは AI が横断検索する。 Amazon Bedrock Knowledge Bases + Amazon Bedrock AgentCore Gateway により、 29 万ファイルに自然言語で即座にアクセス 作業進捗はリアルタイムに見える化。 無線機・モバイル対応で、口頭報告に頼らない進捗管理を実現 フライトの状況は地図上で一目でわかる。 Amazon Location Service により、全機材の航路・空港状況をリアルタイムに可視化 データ変更は自動でカタログに反映。 EventBridge + SQS + Lambda のイベント駆動で運用負荷を最小化 仕様は自然言語で書き、 AI が実装する。 Kiro のスペック駆動開発で、 12 システム・ 79 仕様を効率的に管理・実装 このアーキテクチャパターンは航空に限らず、製造業・物流・医療など、複数の業務システムにまたがるデータを AI で統合検索・分析し、現場の意思決定を支援したい多くの産業で応用可能です。要件を整理すれば、 Kiro で開発できます。 著者 アマゾンウェブサービスジャパン合同会社 エンタープライズ事業統括本部 交通・物流事業本部　シニアアカウントマネージャー 金子 暁人 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 稲田 崇志

こんにちは、楽楽販売開発課のdon （頓花）です。 あるサブシステムをゼロから設計する機会があり、ADR（Architecture Decision Record／アーキテクチャ上の意思決定を記録するドキュメント）を書く場面が一気に増えました。 そこで Claude Code を検討プロセスそのものに組み込んでみたのですが、最初に作った仕組みは、実際に走らせてみるとひどいものでした。エージェントが 1 体で 約60分 動き続ける。工程の境界でユーザー確認が 20 回近く飛んでくる。レビューが 3 巡目に入ってもう何も新しい指摘が出ない。 この記事は、そこから何を直したかの記録です。 この記事で分かること 自分の検討プロセスを工程に分解して Skills に移植する手順 マルチエージェント構成で「全員が会話に参加し続ける」構成をやめた理由 前提情報をリポジトリに置いて AI に読ませる運用 動かしてみて初めて分かった、重い箇所の潰し方 【目次】 足りないのは AI の賢さではなかった 前提: 3 つの仕組みを使い分ける まず、自分が ADR を考える流れを分解する 工程をオーケストラ Skills ＋専門エージェントで構成 全員呼ばない、1 回に集約する 試行錯誤①: 全工程エージェントチームから、サブエージェントへ変更 試行錯誤②: 前提情報を AI が読める形に整理 試行錯誤③: ログを見て Skills 自体を改善 効果と、いまの課題 効果 課題 ADR 以外への応用 まとめ 参考リンク 足りないのは AI の賢さではなかった ADR に AI を使おうとすると下記のようなことがよく発生します。 ひとつは 単発チャット地獄 です。毎回ゼロから前提を説明し直す。「このプロダクトはこういう構成で、過去にこう決めていて……」と貼り直すだけで疲れて、本題に入る前に力尽きます。 もうひとつは 丸投げ です。「いい感じに ADR 書いて」で出てくるものは、形式は整っているのに検討が浅い。観点の抜け漏れが残り、レビューで結局やり直しになります。 どちらも AI の能力の問題ではありませんでした。足りていなかったのは、 自分の検討プロセスを AI が再現できる形にすること でした。 そしてこれは、単に開発が楽になるかどうかの話ではありません。AIへ委譲する割合を増やすことで並列で作業ができるようになり、開発速度を上げることができるようになります。 前提: 3 つの仕組みを使い分ける 本題ではないので手短に触れます。Claude Code には次の 3 つの仕組みがあります。 Skills : 「こういうときはこう進める」という手順書を Claude Code に持たせる仕組み サブエージェント（subagent） : タスクを独立したエージェントに渡し、結果だけ受け取る。呼ばれたときだけ動作するため、呼び出し元の文脈を汚さずに実施できる仕組み エージェントチーム（Agent Teams） : 複数のエージェントが互いにメッセージを送り合って議論する仕組み 。全員が会話に参加し続ける のが特徴 ※ 詳細は公式ドキュメントを参照: Skills ／ subagents ／ Agent Teams まず、自分が ADR を考える流れを分解する AI に渡す前にやったのは、 自分の頭の中の工程を言語化する ことでした。ここを飛ばして skills を書き始めると、結局「いい感じに」と書いてあるだけの手順書になります。 ADR 検討を、動詞ベースで次の工程に分けました。 前提固め → 計画 → 案出し →（検証）→ 独立評価 → 合議 → ドラフト化 →（実装） 工程 要否 やること 前提固め 前提・スコープ境界・完了条件をユーザーと対話して合意する。 既存の決定・仕様・API 定義もここで走査する 計画 この論点ではどの専門家を呼ぶか、どこまでやるかを決める 案出し 選択肢を出し、各案を最新の一次情報で詳細に調べる 検証 任意 判断に動作確認が要るなら、使い捨ての PoC を作る 独立評価 専門家が各自 独立に 案を評価する（あえて合議させない） 合議 出そろった評価をもとに方針を確定する ドラフト化 ADR 本体を書く 実装 任意 採用案を試しに実装する 設計時に気にした点は2点です。 先頭の「前提固め」で、人間の判断を最初に組み込む。 ここでスコープ境界と完了条件をこちらが合意します。後工程がいくら賢くても、前提がずれていれば的を外した ADR が出てくるだけです。 明確にステップを区切る。 これにより作業ごとにコンテキストを分けられるためトークンの節約やコンテキスト肥大化の抑制につながります。 工程をオーケストラ Skills ＋専門エージェントで構成 分解した工程を、ひとつの大きな Skills（オーケストラ役）が指揮し、工程ごとに専門エージェントを呼ぶ構成にしました。 編成は次のようになっています。読者のみなさんが自分のプロセスに置き換えるときの参照にしてください。 区分 体数 役割 モデル 指揮役 1 計画を立て、呼ぶ専門家を選ぶ 重め 調査・案出し役 1 前提の下調べと選択肢の整理 軽め 集約・執筆役 1 議論をまとめ ADR をドラフト 重め 検証役 1 使い捨て PoC（任意工程） 軽め 常駐レビュアー 1 全工程に伴走し観点を採点 軽め 反論役（Devil's Advocate） 1 必ず 1 件以上の反論・Blocker を出す 軽め 領域別の専門家 5 言語 2・DB・API 契約・Python 系 軽め 横断的な専門家 4 運用・インフラ・クラウド・セキュリティ 軽め プロダクト知見の専門家 1 既存プロダクトとの整合・移行・業務観点 軽め 横断ルールのチェックリストを常駐レビュアーの必須参照にし、逸脱を Blocker として報告させ、事例を追記して育てる循環 進行を指揮する役と、最後に決定をまとめる役だけ重いモデルを割り当てています。ここは判断の質が成果物に直結するためです。それ以外は軽いモデルで十分でした。 全員呼ばない、1 回に集約する エージェントを 16 体も定義すると、素直に組めばコストが爆発します。抑えるために入れた工夫が 4 つあります。 専門家を毎回全員呼ばない。 指揮役が論点を分類し、必要な数体だけ起動する。 （ex: DB の話が出てこない ADR に DB の専門家は不要なため起動しない。） 専門家の起動を 1 工程に集約する。 同じ専門家を案出しから実装まで何度も叩き直さず、独立評価の工程で 1 回だけ評価させます。 重いレビューはドラフト工程の 1 回だけにする。 別系統のレビューを挟むのは仕上げの手前だけです。 常駐の 2 体は工程ごとに起動して破棄する。 常駐レビュアーと反論役は全工程に伴走しますが、チームとして常駐させるのではなく、工程ごとにサブエージェントとして呼び直しています。 エージェントを増やすのは簡単ですが、実際に重いのは「どの工程で、どの論点のときに呼ぶか」を決める作業のほうでした。 試行錯誤①: 全工程エージェントチームから、サブエージェントへ変更 最初は 全工程をエージェントチームでやろうとしました 。 複数の専門家が議論しながら設計を詰める構成にしました。理論上はコンテキストも節約しながら進められる想定でした。 しかし、実際には全員が会話に参加し続けるので コンテキストが急速に肥大 し、評価が出そろう前から議論が混線するようになりました。それによりそれぞれの主張が曖昧になり、セッションが長くなりトークン消費量も増大しました。 （ Claude Code でMaxプランの5時間制限の30%近くを1セッションで消費しました。） そこで構成を切り替えました。 既定はサブエージェント方式 にする。独立に呼び出し、結果はファイルで受け渡す。 合議の工程も、まずは指揮役が評価を読んで直接まとめる 方式を既定にする。 エージェントチームは明示的に指定したときだけ 使う（重い論点で本当に対話が要るケース） 試しに同じタスクを比較すると、セッションの稼働時間が改善後（サブエージェント案）は改善前（エージェントチーム）の 約 1／3 になりました。 ※ ただしこれは 1セッションのみ での計測結果です。 得られた教訓は「マルチエージェント＝エージェントチームを常用する」ではなかった、ということです。 対話が本当に要る工程だけチーム、それ以外は独立したサブエージェント という使い分けが、コンテキスト効率に効きました。 もっともこれは私のケースでの結果です。エージェントチームの使い方を詰めれば別の最適点があるはずで、エージェントチーム自体が悪いという話ではないと考えてはいます。 試行錯誤②: 前提情報を AI が読める形に整理 手順（Skills）が良くても、 前提が無ければ検討は浅くなります 。専門家エージェントに「このプロダクトならこの方針」という前提が無いと、教科書的な一般論しか返ってきません。 そこで前提情報を 4 カテゴリに整理して、コンテキストとしてAIに明示的に渡すようにしました。 プロダクトの特性・大方針 既存の決定 : 決定済みのADR のリスト 横断ルールのチェックリスト : 承認済みの ADR で確定した設計判断のうち、議論で逸脱されやすい項目だけを 1〜数行に圧縮 調査方針 : 学習データの記憶に頼らせず、案出しのたびに最新の一次ソースの調査を必須化 3 番目のチェックリストは、実際の失敗から生まれました。 たとえばマルチテナントのデータ分離方式を「スキーマを分ける」と決めていたとします。ところがエージェントは、論点が変わるたびに「識別カラムを持たせる方式ではどうか」と提案してきます。一般論としては妥当な案なので、毎回それらしい理屈がついてきます。決定済みの前提が渡っていないと、こうした「もっともらしい差し戻し」が延々と発生します。 これを毎回人間が指摘して回るのは無理があります。そこで確定事項をチェックリストにまとめ、 常駐レビュアーと反論役の必須参照 にしました。逸脱を見つけたら Blocker として報告させる、という構造的な対策です。 このチェックリストは、逸脱事例を観測したら都度追記する運用にしています。最初から完璧なものは書けないので、育てる前提で置いています。 試行錯誤③: ログを見て Skills 自体を改善 Skills を書いて終わりにはできませんでした。実際に ADR を通して走らせ、ログを見て重い箇所を 1 つずつ潰しました。 実走で見えた問題 直した内容 単発で 約60分 動き続けるエージェント 出力件数・文字数・想定時間に上限を設ける 工程の境界でユーザー確認が 約20回 既定で自動進行にし、Blocker 検出時だけ停止する レビューが 3巡目 で空転 レビューは2巡までとし、超えたらユーザーに引き継ぐ 通しで走らせた後に「これ ADR で扱う話？」となる事故 冒頭に適格性ゲートを1問だけ置く とくに 2 番目は、自分で書いた Skills に「条件付き自動進行」と謳っておきながら、実際は毎境界で確認を飛ばしていたという間抜けな話です。動かしてみるまで気づきませんでした。 4 番目も同じです。ドラフトまで通した後に「これは ADR ではなく機能方針の話では？」と自分で疑問を持ってしまった。なので最初に「本件は ADR で扱うべきか」だけを 1 問聞き、そうでなければ別の進め方を提案して終わる、というゲートを置きました。 ここで狙ったのは平均時間の短縮ではなく、 極端に重いケースを抑えること です。約 60 分動き続けるエージェントが 1 体いれば、平均がどうであれ体験は破綻します。 効果と、いまの課題 効果 体感として得られたものは 3 つあります。 前提の貼り直し回数が低減 毎回の説明から解放され、検討の中身に時間を使えます。 浮いた時間は、業務課題そのものを理解する側に回せるようになりました。 観点の欠落が低減 反論役が必ず 1 件以上の反論を出すので、後工程で気づいて手戻りする回数が減りました。 AI同士の議論が建設的に 変更前はAI同士の議論が追認会になることがありましたが、 独立評価 → 合議の順にしたことと、合議には反対の立場を持つメンバーを必ず 1 名入れるようにしたことにより建設的な議論になった。（気がします。） 課題 一方で課題も残っています。 効果は体感どまりで、定量的な比較ができていない 前提チェックリストや上限設定の効果は、再実走で検証待ち ADR 専用で、機能要件や詳細設計は対象外 ADR 以外への応用 ここまで ADR を例に書きましたが、同じ型は「検討プロセスを持つ仕事」全般に使えるはずです。実装設計、技術選定、障害の振り返りなど、頭の中に工程がある仕事ならどれも当てはまります。 共通する型はこうです。 プロセスを分解する → 工程を Skills 化する → 前提を AI が読める形にする → 対話が要る工程だけチームにする まとめ AI に丸投げするのでも、単発質問を繰り返すのでもなく、 自分の検討プロセスを移植する 。これが今回いちばん効いた考え方でした。 AI に任せる範囲を広げることが AI ネイティブな進め方だと思っていましたが、実際は逆でした。 人が判断する場所を先に決めるほど、残りを安心して任せられる 。冒頭に「前提固め」を置いたのは、まさにそのためです。 最初の一歩は Skills を書くことではありません。 まず自分が普段どう考えているかを書き出してみること です。 それを Skills に移植し、試し、改善していくことによってAIによる効率化を進めていくことができると思います！ 参考リンク Claude Code 公式ドキュメント Extend Claude with skills Create custom subagents Agent teams