Amazon Web Services ブログ
金融機関が AI-DLC を素早く効果的に運用に乗せる方法
本ブログは “How financial institutions can operationalize AI-DLC quickly and effectively“（2026 年 9 月 23 日公開）を翻訳したものです。
金融機関は AI コーディングエージェントを急速に導入していますが、多くの金融機関には、規制当局や自社のリスクアペタイトを満たすガバナンスの枠組みがありません。その結果、強力なツールが組織の統制の外でコードを生成しています。以前の記事「金融サービスのための AI 駆動開発ライフサイクル」（AI-DLC）では、お客様がこれをどう運用に乗せているかを説明しました。今回はさらに踏み込みます。チームが Amazon の Kiro、Anthropic Claude Code、OpenAI Codex のどれを使っていても、エージェントを組織のルールの範囲内で動かすためのガバナンス層をどう構成すればよいのでしょうか。この記事では、ガバナンスハーネスを数日で構築する方法と、エンジニアリングチームとガバナンス・リスク・コントロール（GRC）チームがそこから何を得られるかを説明します。
ハーネスのガバナンス層
なぜ重要なのか
ガバナンス層がなければ、コーディングエージェントは強力でありながら統制の効かない存在になります。生成されたコードがデータの取り扱いや行動規範のルールに違反するかもしれません。承認されていない依存関係は、問題が起きる可能性を高めます。脆弱なパッケージを通じて、シークレットが意図せず漏えいすることもあります。規制当局は、適切なモニタリングが行われている証拠を見つけられません。ガバナンス層は組織のポリシーを技術的な制約に変換し、コードを書く速さが統制を犠牲にしていないことを確かにします。
主要なコーディングエージェント（ハーネス）は、いずれもガバナンス層を構築するための基本要素を備えています。
| ハーネスの基本要素 | Kiro | Claude Code | OpenAI Codex |
|---|---|---|---|
| 永続的なコンテキスト（エージェントが毎セッション読むルール） | ステアリングファイル（.kiro/steering/） | CLAUDE.md + Rules（.claude/rules/） | AGENTS.md（ディレクトリごとに階層化） |
| イベントに応じた自動の強制（自動アクション） | Hooks（AI フックを含む） | Hooks | Hooks（hooks.json / config.toml） |
| コンテキストを分離したレビュー | サブエージェント（カスタムエージェント） | サブエージェント | サブエージェント |
| 再利用可能なワークフロー | Skills（SKILL.md） | Skills（.claude/skills/） | Skills（.agents/skills/） |
| 外部ツールとの統合 | MCP サーバー | MCP サーバー | MCP サーバー |
| 権限の境界 | エージェント定義の権限ルール | 権限システム（allow/deny/ask ルール） | config.toml の承認ポリシーとサンドボックスモード |
これらのファイルに、その会社固有の標準を書き込みます。ハーネスは、その会社のために、その会社がすでに持っている知識（ポリシー、アーキテクチャ設計ガイドライン、セキュリティ標準など）から作ります。たとえば、コーディングエージェントに設計ガイドラインを読ませ、関連する情報を抽出して、スキル、フック、ステアリングファイル、エージェントに書き込ませます。
ハーネスのガバナンス層がもたらすもの
- エンジニアリングのリーダーにとって： すべての開発者、すべてのエージェントとのやり取りから、一貫してガバナンスの効いた成果物が得られます。新しく加わったメンバーも、リポジトリをクローンするだけで初日からルール一式を引き継げます。
- GRC チームにとって： エンジニアリングの証跡を、規制対応にそのまま使える報告に自動で変換するコンプライアンスの仕組みを作るためのデータが得られます。
- 開発チームにとって： ガバナンスの効いていないコードの手戻りなしに、エージェント型開発の速さを得られます。エージェントはルールから外れる前に確認を求め、チームが学ぶほど組織の知識が蓄積されます。
金融機関のお客様と 3 日間で構築したもの
最近、欧州の大手保険会社と取り組みを行いました。このお客様は、エージェント型開発を使って既存の画面に新しい UI ガイドラインを適用する必要があり、同時に組織のルールへの準拠も保たなければなりませんでした。AI-DLC の Inception フェーズに続いて、お客様のエンジニアが AWS と協力し、ハーネスのガバナンス層と、それを保守するために必要なスキルを 3 日で構築しました。お客様は、ステアリングファイルのアーキテクチャと spec 駆動開発のワークフローを標準で備えている点から Kiro を選びました。
構築したガバナンス層は 6 つの要素からなり、それぞれがコンプライアンス・リスク管理チームになじみのあるリスク統制に対応しています。
| ハーネスの要素 | 役割 | 対応する統制（GRC 向け） |
|---|---|---|
| 永続的なコンテキスト（Kiro のステアリングファイル / CLAUDE.md / AGENTS.md） | エージェントがタスクの前に毎回読むルール | ポリシーと標準、人間が関与するチェックポイント |
| 自動のゲート（Hooks） | 保存時とパイプラインでの決定論的なチェック | 予防的統制と発見的統制 |
| 手順をスキルとしてまとめる（手続きのガバナンス） | 複雑な複数ステップのワークフローを毎回同じ方法で実行する | コンプライアンスに沿ったプロセスの遵守 |
| ナレッジループ | 修正内容を記録し、繰り返し現れるパターンを恒久的なルールに格上げする | 課題管理と統制の改善 |
| 対立的なレビュー（レビュー用エージェント定義を持つ Kiro、Claude Code、Codex のサブエージェント） | マージ前に、コンテキストを分離してエージェントの成果物を批評する | メーカー・チェッカー／職務分離 |
| 権限の境界（権限設定） | エージェントがアクセス・実行できる範囲を制限する | 最小権限／特権アクセス管理 |
取り組みの中で、シニアエンジニアやアーキテクトは、ガイドラインの文書、コード例、チームが持つ組織の知識から、ハーネスの要素を生成するよう Kiro に指示しました。作業は反復的に進めました。チームは最初のハーネスをレビューして明らかな誤りを取り除き、あらかじめ用意したインプットを与え、必要に応じてエージェントを誘導し、出力が期待に届かないたびにハーネスを修正しました。この過程で、実務上の疑問が浮かびました。改善の手段がいくつもある中で、ハーネスを磨くのに最も効率のよい方法は何か、という疑問です。ハーネスを作るためのルールはまだ形になりつつある段階で、厳密に体系化されていません。しかも、新しいモデルがリリースされるたびに変わります。そのため、ハーネスを時間をかけて磨き、適応させていくうえで、チームを導く経験豊富な実務者が欠かせません。
各要素がガバナンスの観点で何をもたらすか
ステップ 1：ルールを定義する（永続的なコンテキスト）
エージェントは、文書化されバージョン管理されたポリシーの範囲内で動きます。すべてのルールには担当者（人間）が 1 人おり、組織の標準までたどることができます。
既存のガイドラインは、各エージェント固有の指示形式に変換します。Kiro ならステアリングファイル、Claude Code なら CLAUDE.md、Codex なら AGENTS.md です。
主な設計原則（エージェントを問わない）：
- ルールを関連するコンテキストに絞る： たとえばフロントエンドの標準はフロントエンドのタスクのときだけ読み込みます。コンテキストが薄まるのを防ぎ、エージェントが関係するルールだけを見るようにします。
- 要件レベルの語彙（MUST / MUST NOT / SHOULD / MAY）： RFC 2119 の制約キーワードを使い、AI エージェントの振る舞いを決定論的にします。これらのキーワードを大文字で書くことで重みが増し、エージェントがより確実に守るようになります。
- 質問を必須にする規律： あいまいな要件からコードを生成する前に、エージェントは必須の質問への回答を集めます。要件の誤解がそのまま顧客向けの誤りになる金融機関にとって、これは価値の高いガバナンスです。
ステップ 2：決定論的な統制を強制する（自動のゲート：Hooks）
決定論的にチェックできる統制は、人間のレビューを経てコーディングエージェントがスクリプト化します。これにより、人為的なミスや AI のハルシネーションの可能性を取り除き、監査人に向けて再現可能な証跡を提供します。
永続的なコンテキストがエージェントの振る舞いを方向づけ、自動のゲートがそれを決定論的に強制します。
- 保存時のコンプライアンスチェック： ファイルを保存するたびにポリシーのチェックが走り、違反はエージェントに戻されてすぐに修正されます。
- 完了前の検証： エージェントは、コンパイル、テスト、lint の結果を示さない限り、タスクを完了と宣言できません。
- 実行前のブロック： 危険な操作は、実行前に人間の承認を必要とします。
これらは、第 2 の防御線として CI/CD パイプラインにも広げます。
ステップ 3：手順をスキルとしてまとめる（手続きのガバナンス）
これまで複雑な複数ステップのワークフローは、開発者の習熟度によって実行方法がまちまちで、逸脱や誤りの原因になっていました。これを、どの開発者がどのセッションで呼び出しても毎回同じ方法で実行できるようにし、組織の手順を書き込んで、準拠した成果物を生み出します。
永続的なコンテキストは、エージェントに何をすべきかを伝えます。スキルは、それをどうやるかを伝えます。スキルはバージョン管理されたディレクトリ（SKILL.md を起点とする）で、指示、テンプレート、スクリプトを繰り返し使えるワークフローにまとめたものです。エージェントは名前でスキルを見つけ、関係があるときだけ指示の全文を読み込み、毎回同じ手順に従います。
- Kiro の場合： .kiro/skills/ にある SKILL.md ファイル。キーワードの一致で見つけられます。
- Claude Code の場合： .claude/skills/ にあるスキルのフォルダ。それぞれに SKILL.md と、必要に応じてスクリプトを置きます。
- Codex の場合： リポジトリ、ユーザー、システムの各スコープの .agents/skills/ にあるスキルのフォルダ。プラグインで配布できます。
スキルは、指針と強制の橋渡しをします。準拠した成果物を生む手順を書き込むことで、フックが発動する回数を減らします。スキルはリポジトリに置かれるため、すべての変更が git で追跡されます。スキルはオープンなエージェントスキルの標準（agentskills.io）に従っているため、ツールが進化しても投資が無駄になりません。
ステップ 4：組織の知識を蓄積する（ナレッジループ）
会社の標準と組織の知識は継続的に改善されます。新しいルールはどれも、git の履歴にある日付付きの修正記録にさかのぼれます（トレーサビリティ）。
コードの修正は、タイムスタンプとタグを付けた事例として、バージョン管理されたファイルに記録します。同じパターンが 3 回繰り返されたら恒久的なルールに格上げし、人間がレビュー・承認した組織の知識として蓄積していきます。
実際には、繰り返し出てくる修正は、新しいステアリングファイルの項目（Kiro）、ルールファイル（Claude Code）、AGENTS.md の更新（Codex）になります。ルールを決定論的にチェックできるなら、スクリプトにします。
ステップ 5：エージェントのためのメーカー・チェッカー（対立的なレビュー）
リスクの高い変更は、人間が目にする前に、独立したコンテキストを分離したレビューを受けます。これは、リスク管理部門が機微な業務に求めるのと同じ職務分離です。
コーディングエージェントがコードを生成し、続いてコンテキストを分離したレビュー用エージェントが、その成果物をステアリングのルールに照らして批評します。承認されるか、人間にエスカレーションされるまで、このやり取りを繰り返します。企業はこれを、欠陥を見逃した場合のコストがレビューのコストを上回るリスクの高い変更に絞って適用します。
ステップ 6：エージェントの能力の範囲を限定する（権限の境界）
エージェントの自律性はエージェント型開発の速さの中心にあり、ここまでの要素でエージェントがすべきことはすでに制約されています。権限の境界は、最後の安全策を加えます。問題を解くときに、エージェントがタスクに必要な範囲を超えられないようにするものです。最小権限のアクセスを設定し、エージェントが定められた範囲の外にあるものを読んだり、変更したり、実行したりできないようにします。
- Kiro の場合： カスタムエージェントの定義で、エージェントが使えるツールの種類（読み取り、書き込み、シェル）を宣言します。
- Claude Code の場合： 4 層の権限システム（モード、allow/deny/ask ルール、フック、OS レベルのサンドボックス）が、すべてのツール呼び出しを、失敗したら拒否する（フェイルクローズの）パイプラインで評価します。
- Codex の場合： 承認ポリシーとサンドボックスモードにより、設定可能な人間の承認と OS レベルの分離を提供します。
人間と違い、エージェントは報告に疲れることがありません。手作業での証跡収集は面倒で誤りも起きやすいものですが、エージェントはコンプライアンスチェックを 1 回目でも 1,000 回目でも同じ厳密さで、ほかのタスクと同じように実行します。そのため、ハーネスの一部を、監査人が求める可能性のある証跡を継続的に集める仕組みとして構成できます。成果物を構造化されたリポジトリに保存しておけば、監査報告書の作成は、記録を作り直す作業ではなく、取り出す作業になります。
ハーネスのガバナンス層のデリバリーパイプライン
ハーネスがガバナンスの役割を果たしていることを、どう検証すればよいでしょうか。ハーネスもソフトウェアの成果物なので、2 つの検証層を持つ専用のデリバリーパイプラインを用意します。
第 1 層：静的検証（コード変更のたび、数秒で）： リンク切れがないこと、フォーマットが正しいこと、ルールに担当者がいること、スクリプトが動くことを自動でチェックします。これにより、ガバナンスの成果物が動き出す前に、正しく組み立てられていることを確認します。
第 2 層：振る舞いの回帰テスト（毎晩、およびモデルが変わるたび）： 正しい出力があらかじめ決まっている既知のシナリオでエージェントを動かし、ルールが実行時に機能することを確かめます。第 1 層は「ルールは正しく設定されているか」を問い、第 2 層は「AI が動いたときにルールは機能するか」を問います。
重要な気づき：ハーネスには継続的な調整が必要
お客様との取り組みから、ガバナンスハーネスは機能することが分かりました。ただし、成功させるには、監視と調整、そしてエンジニアリングチームと GRC チームの共同の責任が必要です。
モデルは進化し、ハーネスもそれに合わせて進化しなければなりません。実践的な指針は次のとおりです。
- 厳格な承認ゲートは、本当に元に戻せない操作だけに残す：新しい依存関係、構造的なリファクタリング、スコープを変える判断など。
- 各ルールは 1 か所に 1 回だけ書き、担当者を 1 人にする。
- ルールは、ドメインやファイルの種類に応じて条件付きで適用する。
- まず、矛盾と参照切れをなくす：整理され、矛盾のないルールセットこそが、品質を上げる最大の手段です。
根底にある原則はおなじみのものです。統制のしすぎは守るべきプロセスを損ない、一貫性のないポリシーは少なすぎるポリシーよりも悪い、ということです。適切な調整の水準はモデルの世代が変わるたびに動くため、ハーネスには回帰テストが必要です。この調整の規律は、定められたリスクアペタイトの範囲でエージェント型 AI のメリットを得るために、GRC 部門が身につけなければならないスキルです。
ハーネスだけでは機能しない
この枠組みは、成熟した DevSecOps のプラクティス（自動化された CI/CD、ブランチ保護、コードレビューの文化）がすでに整っていることを前提にしています。エージェントのガバナンスを上に重ねる前に、まずそこから始めてください。
重要なのは、ステアリングファイルやプロンプトに基づくルールは非決定論的な統制だという点です。エージェントの振る舞いに影響を与えますが、それを保証することはできません。ガバナンスを完全なものにするには、エージェントが何を生成しても準拠を強制する、CI/CD パイプラインの決定論的な統制（linter、静的解析、Policy as Code のゲート）で補う必要があります。ハーネスは、層を重ねた仕組みとして最もよく機能します。非決定論的な統制が生成時の違反を減らし、決定論的な統制が、すり抜けたものをコードが本番環境に届く前に捕まえます。
まとめ
冒頭で示したガバナンスのギャップは解決でき、しかも素早く解決できます。AI-DLC は金融機関に手法を提供し、ガバナンスハーネスは、コンプライアンスを組み込んだ状態でエージェント型開発を大規模に運用するためのツールを提供します。ハーネスは、準拠したコードの実装を容易にすると同時に、実装中に下された判断をより体系的に記録します。その記録が可視性と透明性を生み、開発チームに追加の負担をかけずに、規制対応の証跡に変えることができます。
前提条件は、経営層の合意と、ハーネスが増幅する土台となる成熟した DevSecOps のプラクティスです。投資は、多くの金融機関が想定するより小さくて済みます。基盤となるハーネスは、新たなポリシーを一から作るのではなく、組織がすでに持っている知識から作るため、数日で形になります。
AI-DLC の展開ハーネスの一部として効果的なガバナンス層を構築するために AWS がどのようにお手伝いできるか、詳しくは AWS のアカウントチームにお問い合わせください。