はじめに こんにちは。クロスイノベーション本部サイバーセキュリティテクノロジーセンターの小笠原です。 昨今の脆弱性検査において、以下のHTTPレスポンスヘッダの未設定が検出されるケースが増えています。 COEP（Cross-Origin-Embedder-Policy） CORP（Cross-Origin-Resource-Policy） COOP（Cross-Origin-Opener-Policy） これらはブラウザが提供する「クロスオリジン分離（Cross-Origin Isolation）」を実現するためのセキュリティ機能です。 「設定すると何が変わるのか」「対応は必須なのか」と疑問に思った方もいるのではないでしょうか。 本記事では脆弱性検査の観点からCOEP、CORP、COOPヘッダの役割や検出される理由について紹介します。 なぜ脆弱性検査で指摘されるのか これらのヘッダは以下の観点からセキュリティ強化項目として扱われています。 Spectreのようなサイドチャネル攻撃への対策 一部の高度なブラウザ機能を安全に利用するための要件への対応 昨今のブラウザでは安全な実行環境を確保するため、一部の高度なブラウザ機能を利用する際に「クロスオリジン分離」と呼ばれる状態が求められています。 そのため、脆弱性検査では以下のような観点が確認項目として指摘されるケースが増えています。 ブラウザセキュリティ強化への対応状況 クロスオリジン分離への対応状況 Spectreなどの新しい脅威への備え とはいえ「クロスオリジン分離」や「Spectre」といった言葉に馴染みがない方もいるかと思います。 次章ではまず、本記事を読むにあたって前提となる知識を整理します。 前提知識 本記事を読むにあたり、前提となる用語を先に整理します。 オリジンとは オリジンとはWebサイトを識別する単位であり、スキーム・ホスト名・ポート番号の3つの組み合わせで構成されます。 この3つがすべて一致する場合のみ「同一オリジン」、1つでも異なる場合は「別オリジン（クロスオリジン）」として扱われます。 比較対象 判定 理由 https://example.com と https://example.com/page 同一オリジン スキーム・ホスト・ポートが一致（パスは無関係） https://example.com と https://sub.example.com 別オリジン ホスト名が異なる https://example.com と http://example.com 別オリジン スキームが異なる https://example.com と https://example.com:8443 別オリジン ポート番号が異なる 本記事で扱う「クロスオリジン」とはこのオリジンが異なるWebサイト同士のアクセスを指します。 なお、後述するCORPヘッダの設定値には「サイト」という単位も登場します。 「サイト」はオリジンより広い単位で登録可能なドメイン（例：example.com）が同じであれば、サブドメインが異なっても同一サイトとみなされます。 例えば https://example.com と https://sub.example.com は「別オリジンだが同一サイト」という関係になります。 クロスオリジン分離とは クロスオリジン分離とは信頼できないクロスオリジンとの不要なデータ共有や相互参照を制限し、ブラウザ上でより安全な実行環境を実現する仕組みです。 クロスオリジン分離を実現することでSpectreをはじめとしたサイドチャネル攻撃のリスクを低減できるほか、後述するSharedArrayBufferなど一部の高度なブラウザ機能を利用できるようになります。 サイドチャネル攻撃とSpectre ・サイドチャネル攻撃とはプログラムの処理内容そのものではなく、処理にかかる時間やメモリの挙動といった「副次的に漏れ出る情報」を手がかりに本来知り得ない情報を推測する攻撃手法です。 ・Spectreはその代表例でCPUの投機的実行（先の処理を予測して先回りで実行し、高速化する仕組み）を悪用し、本来アクセスできないメモリ上の情報を推測して取得するサイドチャネル攻撃です。 これらの攻撃はブラウザ上で複数オリジンのデータが同じプロセスに同居していると成立しやすくなります。 そのため、オリジン同士を分離するクロスオリジン分離が対策として有効です。 クロスオリジン分離を必要とする代表的なブラウザ機能 以下のような機能は安全に利用するためにクロスオリジン分離を必要とします。 SharedArrayBuffer 複数スレッド間でメモリを共有できる機能 performance.measureUserAgentSpecificMemory() Webページが使用しているメモリ量を詳細に計測する機能 高精度タイマー（performance.now()など） マイクロ秒単位で処理時間を計測できる機能 WebAssembly Threads WebAssemblyによるマルチスレッド処理を実現する機能 これらの機能を安全に利用するためにはCOOPやCOEPを適切に設定し、クロスオリジン分離を実現する必要があります。 3つのヘッダの全体像 各ヘッダの詳細に入る前にまずCOEP・CORP・COOPの役割を俯瞰します。 3つのヘッダはそれぞれ異なる観点からクロスオリジンアクセスを制御します。 COEP：外部リソースを読み込む側の制御 怪しいものは読み込まない CORP：リソースを提供する側の制御 自分のものは勝手に使わせない COOP：他サイトとのウィンドウ関係の制御 他サイトとのつながりを切る それぞれ役割は異なりますが共通する目的は「信頼できないクロスオリジンとの不要な関わりを減らすこと」です。 これらを組み合わせることでクロスオリジン分離が実現され、より安全な実行環境を構築できます。 なお、クロスオリジン分離はCOOPとCOEPの両方を設定して初めて成立します（CORPはCOEPを補助する役割です）。 どちらか一方だけでは分離状態にはならない点に注意してください。 具体的な設定値は次章以降で各ヘッダごとに説明します。 以降で、各ヘッダの詳細を順に見ていきます。 COEPヘッダとは 概要 COEPヘッダは「利用が明示的に許可された外部リソースのみ読み込む」ためのヘッダです。 Webサイトでは画像やJavaScript、iframeなどの外部リソースを利用することがあります。 COEPヘッダを設定するとクロスオリジンリソースの取り扱いが制限され、利用が明示的に許可されていないリソースはブラウザによってブロックされます。 図1. COEPによるクロスオリジンリソースの読み込み制御 出典： web.dev「優れた機能のために『クロスオリジン分離』が必要な理由」 https://web.dev/articles/why-coop-coep Licensed under CC BY 4.0. 設定値は以下のとおりです。 require-corp：CORSまたはCORPで利用が許可されたリソースのみ許可 credentialless：認証情報を送信しない条件で一部のクロスオリジンリソースを許可 unsafe-none：制限なし（デフォルト） ※CORS（Cross-Origin Resource Sharing）とはあるオリジンのページから別オリジンのリソースへのアクセスをリソース提供側が許可する範囲で認める仕組みです。 効果 安全性が確認できない外部リソースの読み込みを防止する クロスオリジン分離を実現し、Spectre などのサイドチャネル攻撃のリスクを低減する CORPヘッダとは 概要 CORPヘッダは「自サイトのリソース利用範囲を制御する」ためのヘッダです。 例えば、自サイトで公開している画像やJavaScriptなどのリソースを意図しない外部サイトから利用されたくない場合に使用します。 CORPヘッダを設定することで自サイトのリソースがどのサイトから利用できるかを制御でき、外部サイトによる意図しない利用を防ぐことができます。 設定値は以下のとおりです。 same-origin：同一オリジンのみ許可 same-site：同一サイトのみ許可 cross-origin：すべてのオリジンからの利用を許可 効果 自サイトのリソース利用範囲を制御する リソースを提供する側からクロスオリジン分離を支援する COOPヘッダとは 概要 COOPヘッダは「他サイトとのウィンドウのつながりを切り離す」ためのヘッダです。 例えば、外部サイトが window.open() を利用して自サイトを開いた場合、通常は開いた側と開かれた側の間に関係が残り、開いた側のページは開かれたページのウィンドウを参照したり、ページ遷移を引き起こすことができます。 COOPヘッダを設定するとこの関係が分離され、外部サイトから自サイトのウィンドウを参照・操作できなくなります。 図2. COOPによるブラウジングコンテキストの分離 出典： web.dev「優れた機能のために『クロスオリジン分離』が必要な理由」 https://web.dev/articles/why-coop-coep Licensed under CC BY 4.0. ※ブラウジングコンテキストとはタブやウィンドウ、iframeなど、Webページが表示・実行される単位を指す用語です。 COOPはこの単位同士のつながりを制御します。 設定値は以下のとおりです。 same-origin：同一オリジン以外とのウィンドウ関係を分離する same-origin-allow-popups：自ページが開いたポップアップとのウィンドウ関係は維持し、それ以外は分離する noopener-allow-popups：ポップアップを開くこと自体は許可するが、開いたポップアップとのウィンドウ関係は分離する unsafe-none：制限なし（デフォルト） 効果 外部サイトとのウィンドウ関係を分離し、クロスオリジン間の不要な連携や影響を抑制する クロスオリジン分離の確認方法 クロスオリジン分離が有効になっているかはブラウザの開発者ツール（Console）で以下を実行することで確認できます。 self.crossOriginIsolated 実行結果が「true」の場合はクロスオリジン分離が有効です。 一方、「false」が表示された場合はCOOP（same-origin）とCOEP（require-corpなど）のいずれかが未設定であるか、読み込んでいるリソースがCORS/CORPの要件を満たしていないなどの理由でクロスオリジン分離が成立していない可能性があります。 対応は必須か COEP、CORP、COOPヘッダは未設定だからといって直ちに脆弱性となるわけではありません。 判断の軸は「クロスオリジン分離（COOP＋COEPの併用）が必要か」と「個々のヘッダによる保護が必要か」を分けて考えることです。 以下のような場合は設定を検討することが推奨されます。 SharedArrayBufferなどクロスオリジン分離を必要とする機能を利用する場合（COOPとCOEPの併用が必須） ブラウザセキュリティを強化したい場合 脆弱性検査やセキュリティ基準への対応が求められる場合 クロスオリジン分離を必要とする機能を使わないサイトではCOOPとCOEPを厳格に設定する必要は必ずしもありません。 ただし、その場合でもCOOP（same-origin）単体はタブナビングなどウィンドウ経由の攻撃対策として、CORP単体はリソースの意図しない外部利用の防止としてそれぞれ単独でも有効です。 このように「クロスオリジン分離としての対応」と「個別ヘッダによる保護」を切り分け、自サイトの要件に応じて対応範囲を決めることが望ましいでしょう。 Tips：COEP、CORP、COOP導入時の注意点 COEP、CORP、COOPはセキュリティを強化する一方で、既存システムへ適用する際には注意が必要です。 COEP適用時は外部リソースの動作に注意する COEPを有効にすると外部CDNから配信される画像、JavaScript、iframeなどが読み込めなくなる場合があります。 特に以下のようなリソースを利用している場合は事前の動作確認を推奨します。 CDN配信のJavaScript アクセス解析ツール 広告タグ 外部サービスが提供するiframe COOP適用時は外部サービス連携を確認する COOP（Cross-Origin-Opener-Policy）を有効にすると異なるオリジンのページとのウィンドウ関係が分離されます。 これにより、従来は利用できていたwindow.openerなどのウィンドウ間参照が制限され、異なるサイト間での情報の受け渡しや連携処理に影響を与える場合があります。 そのため、以下のような機能では動作に影響が発生する可能性があります。 OAuth認証 シングルサインオン（SSO） 決済サービス window.open() を利用する機能 例えば、認証サービスや決済サービスがポップアップウィンドウを開き、認証や決済完了後にwindow.openerを利用して元の画面へ結果を通知する実装の場合、COOPによってウィンドウ間の参照が切り離されることで正常に連携できなくなる可能性があります。 ポップアップとの連携が必要な場合は、影響範囲を十分に確認したうえでsame-origin-allow-popupsの利用も検討してください。 まとめ 本記事では脆弱性検査で検出されることが増えているCOEP、CORP、COOPヘッダについて紹介しました。 これらのヘッダはそれぞれ異なる観点からクロスオリジンアクセスを制御し、組み合わせることでクロスオリジン分離（Cross-Origin Isolation）を実現します。 その結果、Spectreをはじめとするサイドチャネル攻撃のリスクを低減できるほか、SharedArrayBufferなどの高度なブラウザ機能を利用できるようになります。 検査結果でCOEP、CORP、COOPヘッダの未設定を指摘された際は単なるHTTPヘッダ不足ではなく、現代ブラウザのセキュリティモデルへの対応状況を示す項目として捉えてください。 本記事がCOEP、CORP、COOPヘッダに対する理解を深める一助となれば幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @ogasawara.shota レビュー： @yahagi.ginpei1128 （ Shodo で執筆されました ）

1.はじめに こんにちは、OpenInnovationラボ（通称イノラボ）の奥野正寛です。 現在イノラボではフィジカルAIの研究開発に取り組んでおり 前回記事 では、小型アームのSO-ARM101を使い、VLAモデルであるπ0.5の精度や汎化性を検証しました。 今回は業務利用を見据え、業務向けレベルにパワーと精度がある協働ロボットとしてxArm7を2台で双腕のロボット基盤モデル検証システムを構築し、実証したことについて書きたいと思います。 今回の検証ではπ0.5で以下2つの内容を検証しております。 本記事では、取り組んだ内容と併せてVLAをxArmのような協働ロボットに適応するにあたり苦労したことや、実際に実機で動かしてみて分かったことなどをお伝えします。 検証①：基本的なピック＆プレイス 検証②：ラボオートメーションを想定した「電子レンジで資材を温める」というロングタスク 2.独自のRFM実証システムを構築 今回ロボットとしてUFACTORYの xArm7を2台組み合わせた双腕構成 にしました。 操作インターフェースには各アームに対応するGelloを使い、直感的かつ精度高くxArmを制御してデータ収集できる構成を目指しました。 システムはLeRobot0.6.1をベースに開発し、データ取得や学習済みVLAモデルを実行できるシステムを構築しました。 カメラは各アームの手首にRealSense1台ずつと、空間全体を見るUSBカメラ1台の計3台です。 データ取得では、何百回とエピソード動作を繰り返すためデータ記録の効率性を考慮し、 フットスイッチで記録終了や次のエピソードの記録開始を行えるようにしました。 Gelloから手を離してPCを操作する必要がなく、両手でロボットを操作しながら、効率よくデータを収集できました。 タスクによってはエピソードの初期状態に戻すことも、ロボットを制御して行うこともできます。 また実証システム開発において考慮した点として安全性があります。xArmのように大きくてパワーがあるロボットの場合、制御によっては周囲への危害だけでなくロボット自体の破損の懸念があります。 今回は対策の一例として、VLAによる制御時にはロボットに制御値を送る前に各関節への指令値の変化量に上限を設けるフィルターと、移動平均によるスムージングをかける構成としてます。 また、扱う物体や作業に合わせて、グリッパーの先端治具を3Dプリンターで作成しています。 特に今回は電子レンジの庫内へのアクセスの際に手首カメラが衝突してしまうことが判明したため、掴みやすさだけでなくグリッパー先端を長くする調整が必要でした。 世の中のフィジカルAIの事例を参考にFin-Ray形状の治具を作成しましたが、曲がりやすさなどは作って試さないと分からないため微調整しながら最終形状を設計してます。 他にもGelloの固定台座なども3Dプリンターで作成しており、ロボットをやるうえで3Dプリンターは必須であると改めて感じました。 3. 検証①：π0.5による基本的なピック＆プレイス 基本動作ができるまでの試行錯誤 まずはシンプルなピック＆プレイスのタスクで、システム全体が想定通りに動作することを目指しました。 SO-ARM101での経験があったため、同じようにデータを集めてπ0.5をファインチューニングすればある程度は動かせると考えていましたが、最初は期待する精度が出ず試行錯誤を繰り返しました。 トライ1 最初は左右それぞれ50回ずつそれぞれ別アイテムをピック＆プレイスするデータを取得しπ0.5を学習したモデルを試しました。 プロンプトの切り替えでそれぞれのアイテムを取れることを期待しましたが、片方のプロンプトはそれらしい動作はするが、もう片方のプロンプトはほとんど動かなくなるなど全く成功しない結果となりました。 原因を検討した結果、以下点を想定し、システムを見直したうえでトライ２へ移行。 空間カメラ配置の見直し ・最初は作業机の真上から真下を見下ろす形で空間カメラを設置しましたが、これだと映像に含まれる位置情報が２次元となり、高さに関する情報が不足すると考えました。 ・Physical Intelligenceなどの主要なVLAベンダーのデモ動画を参考にすると、双腕の間の上方部から見下ろす位置に空間カメラを設置していることが多く、上下の情報も取れる位置であることから同様の位置に変更しました。 片腕固定による条件を絞った ・今回双腕のそれぞれが動くと固定カメラは空間カメラ1台となり、残りの２カメラが動くとなるとカメラ位置の条件が相当多いことになると考えられます。そこで片腕を固定してカメラとして使い、まずは単腕アームシステムの状態として検証することにしました。 ・前回SO-ARMで実施した検証では2台のカメラを固定カメラとして、100~200回程度のエピソードデータである程度ピック＆プレイスに成功するモデルが学習できていたことを参考としてます。 トライ2 上記のカメラ位置変更、単腕アーム化した状態で1つのアイテムに対するピック＆プレイスを検証。 しかしそれでも精度が出ないことから他のシステムバグやデータ不整合などを中心に見直しました。 結果としてグリッパーのデータが正しく保存できていない、実際の動作時間と記録データの時間がずれがあった、Lerobot自体のバグなど様々な要因が発見されました。 厄介だったのは、こうした問題があっても「なんとなく動いてしまう」こと データが足りないのか、学習がうまくいっていないのか、制御側の問題なのか問題切り分けが必要となります。 環境整備・データ取り・モデルFT・実機検証・要因分析を繰り返す ことにより期待する精度のシステムの構築ができます。この繰り返しをいかに効率的に実施するかが重要だと感じました。 またこれまでの経験から、VLA実行時に様々な初期状態に対応するためには収集データにおいて、対象物の置き方の網羅性が重要であると考えました。 そこで初期条件としての置き方の網羅性を確認するために、各エピソードデータから重畳画像で確認できるツールを作りました。 以下の画像のように学習データにおいてどこに置いてないが一目で分かることで、学習後モデルで精度のでない位置条件の原因が切り分けやすいです。 データ条件が少ない場合はあまり問題なかったですが、条件が増えてくると分からなくなってくるためこういった確認方法は有効だと感じます。 最終トライ 最終的にこれまでの不具合要因を修正し、単腕で200回程度のデータを使うことで、期待するピック＆プレイスができるπ0.5のモデルを作ることができました。 このプレ検証ではπ0.5の対象物に対する汎化性を確認することができました。 「ニンジンを掴んで皿に置く」動作のデータのみで学習したπ0.5モデルに対して、実行時に入力プロンプトを変えると、 掴む対象として学習していないピーマンやナスでもピック＆プレイスに成功 する挙動が見られました。 ニンジンがある場合、プロンプトで他のアイテムを指定してもニンジンを取りにいく挙動です。 またタスク終了条件となるニンジンが皿に乗った状態においても、他のアイテムには反応しない状態となります。 ニンジンがない状態で、プロンプトでピーマンやナスを指定するとそれぞれのアイテムを取りにいくことが出来ました。 学習時に掴む対象として扱っていない野菜にも対応できたことから、対象物に対して汎化した結果が見られました。 サイズや形状が異なる赤パプリカに対しては、指示に反応して取りにいくが掴むことはできませんでした。 ニンジンに対する把持動作だけ学習しているため、パプリカの大きさに合わせたアクションが生成できなかった可能性が考えられます。 4. 検証②:ラボ作業をサブタスクに分けて検証 本検証では業務向け活用のユースケースとしてラボオートメーションを想定し、「電子レンジで資材を温める」という長いタスクを設定しました。 1つのモデルで一気に全タスクを動作させる方法もありますが、π0.5において複雑かつ長いタスクを一気に実行することは精度が出ないと考えました。 π0.5の論文でも内部的に上位で全体タスクからタスクへ分割し、アクション生成する２段階のフローとなっています。したがって今回はπ0.5の考え方に沿って、全体タスクを8つのサブタスクに分け、7つの別モデルに分ける形で検証しました。 結果としてサブタスクごとの専用モデルでは、7つのうち「5.温め実行」を除く6つで成功することを確認できました。 「電子レンジで資材を温める」をサブタスクへ分解 1.コップにジェルを入れる 2.レンジを開ける 3.コップを庫内に入れる 4.レンジを閉める 5.温め実行 (2.レンジを開ける) 6.コップを取り出して資材を落とす 7.温めた資材をカゴに入れる 単腕でのタスク実行 単腕の比較的単純な動作であれば、200回程度のデータである程度の精度が得られました。 また「4.レンジを閉める」のようにある程度決まった位置でアームを動かせば成功するタスクでは100回程度のデータでもほとんど成功するモデルとなりました。 ただし、対象物の位置が変わると失敗するケースも多くあり、1モデルにつき200回程度ではデータに含めたすべての位置に対して安定して動くまでの精度にならない結果です。 双腕でのタスク実行 今回のサブタスクの中で「1.コップにジェルを入れる」だけ双腕で同時に2つのアームを動かすタスクでした。片方のアームでコップを持ち、もう片方でジェルを掴んでコップに入れて、コップをレンジの横に置く、というタスクを1つのモデルに学習する形で検証しました。 コップとジェルの位置条件を満遍なく変更した約300回分のデータで学習した結果、 うまくいく特定の初期位置の条件でのみ成功しました。 学習データに含まれるほとんどの位置条件でジェルやコップを掴むことができず、位置に対する汎化性が得られない結果です。 固定カメラが1台となる双腕の協調動作においては、単腕に比べて必要とされるデータ量が相当に多くなると考えられます。 「押せたか分からない」ボタン操作の難しさ 今回のサブタスクの中で唯一成功しなかったのは、電子レンジの3つのボタンを順番に押す「5.温め実行」タスクです。 200回分のデータで学習し、ボタンを押した結果が分かるようにカメラで液晶表示の変化も映しましたが、モデル実行するとグリッパーの先端でボタンを押しにいくような動作はするものの、ボタンは押すことは出来ませんでした。要因として大きく2つあると考えています。 要因1：ボタンを押せた判断情報がない 人間はボタンを押した際の操作音や押したクリック感で判断できます。一方今回の学習データには音や力覚の情報が含まれておらず、カメラに映した液晶表示の変化だけでは、ボタン押下の成否判断として不十分だった可能性があります。 要因2：先端の微小な動作を学習不足 今回グリッパーの治具で先端を延長しているため、ロボットの各関節の角度変化が先端部では大きな位置ずれにつながりやすくなります。今回の構成ではVLAは各関節角度を出力しており、ボタンを押すほどの正確な先端の位置制御を再現するほどには学習できていないと考えられます。 実用化を考えると、こうした課題をVLAの学習だけで解決しようとするよりも、IoTボタンなどの外部機器や別システムとの連携によって、確実に操作できる仕組みを取り入れることも有効だと感じています。 5.プロンプトの切り替えから、モデルの切り替えへ方針転換 もともとこの検証を始めた際はサブタスク別に入力プロンプトは分けるが1つのモデルに全てのサブタスクのデータで学習させ、プロンプトで実行するサブタスクを切り替えることを想定していました。 しかし実際やってみると2つ3つのサブタスクでも1つのモデルにまとめて学習すると、プロンプトを切り替えてもほとんどのタスクが成功しないモデルとなってしまう結果でした。具体的にはプロンプトの切り替えても関係ないサブタスクの動作をしてしまったり、各サブタスクに近い動作はするものの全く成功するような動きにならないなどです。 プロンプト設計により切り替えられる可能性も考えられましたが、ここでは方針転換しサブタスクごとにモデル自体を別に作る形としました。 結果として前述の通りで多くのサブタスクで成功するモデルを作ることができました！ しかしモデル自体を切り替える場合、モデルの切り替え時にVRAM読み込み等で長い時間がかかることが、業務利用を想定すると課題として残ります。 この課題の回避策を検討し、大きいVRAMへ2つのモデルを同時に読み込ませ実行するモデルを順次切り替え、実行終了したモデルは破棄・・ということを繰り返すことで即座にモデル切り替える形を構築しました。 π0.5は実行時に1つのモデルで10GB程度VRAMを消費します。今回の実行環境ではVRAMが32GBあるRTX5090では、2つのデルの同時展開を問題なく実現できてます。 以下が最初の4つのサブタスクのモデルを順次切り替えて実行している様子です。 6.まとめ 今回の実証では、LeRobotと双腕のxArm7で独自のロボット基盤モデル検証システムを構築し、π0.5による対象物への汎化や、ラボを題材としたロングタスクへの適応を検証しました。 長いタスクでもサブタスクに分解し、それぞれ専用モデルとして学習することでサブタスクを実現できること、またそれらの専用モデルを順次切り替える構成により連続実行できることを確認できました。 一方で現場導入を想定すると位置などの条件に対する汎化性や精度を高めることが必要で、そのためにはやはり大量のデータ収集、そのための効率的なデータ取得やデータ管理・運用が重要となります。 今回の検証では扱うデータや学習済みモデルの容量も膨大になりました。データの管理や学習環境などのインフラ整備、そのためのクラウド費用が課題となるため データ収集から管理・学習・実機評価までを、費用も含めて効率よく回せる環境づくりが重要 だと感じています。 また今回は精緻な操作のためにGelloを使いましたが、1本のアームを細かく動かすには両手が必要で、双腕のデータ収集は2人必要で動きを合わせて行う必要がありました。今後はUMIなどの操作インターフェースも検討し、データ品質と収集効率を両立できる方法を探っていきたいと考えています。 7.最後に 試行錯誤をしている間にも、技術は大きく変化しています。 GeneralistのGEN-1.5 のように 少数の手本でタスクに対応するワンショット・フューショット学習の成果が登場しています。 また、Astraのような最新LLMで追加学習を行わずにロボットを制御し、シミュレーションでは一定の成功率が出る報告がされるなど、この数ヶ月はフィジカルAIにおける大きな技術進化と、進化スピードがより早く広くなってきていると感じます。 新しい技術の可能性も含め、自分たちの環境で実際に動かして確かめ、その過程で出来ることや出来ないことを見極めることが重要だと考えており、イノラボでは引き続きフィジカルAIの社会実装を目指した研究開発を進めていきます。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @okuno_takahiro 、 @miyazawa.hibiki レビュー： @azeta.takuya （ Shodo で執筆されました ）

1.はじめに 2.π0.5とは？ Physical Intelligenceが開発したVLA 高レベル判断と低レベル制御 3.今回の検証環境 4.今回の検証概要 設定したタスク 5.検証結果 検証①：SmolVLAとπ0.5の比較結果 検証②：π0.5のフルチューニングとVLMフリーズの違い 検証③：π0.5のチューニングStep数による違い 6.番外編：LeRobotバージョン違いによるハマったこと 7.まとめ 1.はじめに こんにちは、OpenInnovationラボの奥野正寛です。 前回の記事 では、Hugging FaceのLeRobotとSO-ARM101を組み合わせた環境で、軽量なVLAモデルであるSmolVLAを検証しました。SmolVLAはある程度のデータ量で単一タスクの成功率を8割以上とできたり、1つのモデルでプロンプトを切り替えて複数タスクをそれぞれ実行できることを確認できました。 今回はその続編記事として、より大きなVLAモデルである Physical Intelligenceのπ0.5 を同じSO-ARM101環境で検証した内容について紹介します。 前回と同様に、細かい実行コードなどは記載せず、VLAモデルによる差やファインチューニングのパラメーター変更で何が変わるのか、実際に動かしてみてどんな課題があるのかを中心にお伝えしたいと思います。 なお今回も、 Hugging FaceのLeRobotを使ってモデル学習からロボット制御実行まで を行っています。 ただし後述するとおり、π0.5の論文で紹介されている高レベルのサブタスク生成機能はPhysical IntelligenceやLerobotから公開されているコードに含まれてません。 そのため本記事ではLeRobotで提供されているπ0.5系の実装を使って、画像やタスク指示からロボットのアクション生成する部分を中心に検証しています。 2.π0.5とは？ Physical Intelligenceが開発したVLA π0.5は、Physical Intelligenceが発表したVLA（Vision Language Action）モデルです。 前回の記事で扱ったSmolVLAと同じく、画像とテキストからロボットのアクションを出力するモデルですが、π0.5はより広い環境への汎化を強く意識したモデルとして紹介されています。 公式ブログでは、家庭内の片付けやベッドメイキングのように、環境ごとに物体の位置や種類が大きく変わるタスクでの検証が示されています。ロボットが現実世界で使われるためには、決まった工場ラインのような環境だけでなく、毎回状況が変わる環境でも動ける必要があります。 π0.5はそのような新しい環境で活用できることを目指したVLAとされています。 なおPhysical Intelligenceからはπ0.5の後続のπ0.6、π0.7も発表されていますが、本記事執筆時点で公開されているモデルはπ0.5までとなっています。 高レベル判断と低レベル制御 π0.5の特徴として、単に低レベルのモーター指令を出すだけでなく、タスクを進めるための高レベルな次の行動を言語的に推論し、そのうえで低レベルのロボットアクションを出力する構成です。 例えば「キッチンを片付ける」という大きな指示に対して、「皿をシンクへ運ぶ」「スポンジで拭く」といったサブタスクを推論し、そこからロボットの関節動作に落とし込む２段階の考え方です。 ただしPhysical Intelligenceから公開されているコードや、今回の実証で使用した Lerobot版のπ0.5ではサブタスク計画の生成は含まれていません。画像やタスク指示をVLMで処理し、その情報からAction Expertがロボットのアクションを生成する構成となっています。 そのため、本記事での検証も、論文で紹介されている高レベルのサブタスク生成を含むものではなく、与えられたタスク指示に基づくアクション生成を対象としています。 3.今回の検証環境 ロボットと実施環境は前回記事と同じです。 フィジカルAIの実力は？SO-ARM101でSmolVLAを検証してみた . ただしπ0.5のファインチューニングはRTX5090だとスペック不足であるため、Azure上にH100のインスタンスを構築して実施しております。また前述の通り今回の検証ではπ0.5の論文で説明されているような、高レベルなサブタスク推論、長時間の家庭内タスク実行といった要素はなく、あくまでシンプルなピック＆プレイスをLeRobotで実行可能な範囲で行ったπ0.5の検証となります。 4.今回の検証概要 今回の検証は3パターンで実施しました。 前回のSmolVLA検証で見えた課題を踏まえ、モデルによる差異と、チューニング方法によってどのような差が出るのかを確認しました。 検証① ： SmolVLAとπ0.5の違いを確認する 検証② ： π0.5のフルチューニングと、VLMフリーズの違いを確認する 検証③ ： π0.5のチューニングStep数による違いを確認する 設定したタスク タスクは前回と同じく、アイテムを黄色のカゴに入れるピック&プレイスです。 学習データ取得時は、各アイテムの初期位置をある程度固定しつつ、位置ずらしの条件も加えました。 全てのモデルにおいて4種のアイテムそれぞれについて実施したデータを全て含んだデータセットでモデルをファインチューニングしてます。（英文がモデルへの入力プロンプト） 紫色のボール：Pick up only purple ball and put in yellow basket 黄色のボール：Pick up only yellow ball and put in yellow basket 赤色のキューブ：Pick up only red cube and put it in the basket 青色のキューブ：Pick up only blue cube and put in yellow basket また検証時には学習データに含まない緑キューブと紫キューブのプロンプトで実行することで、色に対する汎化性を検証しました。 5.検証結果 検証①：SmolVLAとπ0.5の比較結果 以下はSmolVLAとπ0.5で、指示文と置いた位置の組み合わせを変えたときの結果です。 指示文がモデル実行時にプロンプトで指示したアイテム、列に記載のアイテムが学習データで置かれていた位置に置いた状態で実行し、10回実施して成功した回数を記録してます。 SmolVLAは、学習時に想定した組み合わせでは比較的高い精度で動きました。 一方で、置いた位置を変えた場合や、指示文と物体位置の関係が変わる条件では、ほとんど成功しない結果で汎化性が低いことが分かります。 π0.5では紫ボールを黄色ボールの位置に置くなど、指定したアイテムが学習時と違う位置でも高い成功率となるケースがありました。 また学習データにない紫キューブ、緑キューブに対しても成功するケースもあり、π0.5はSmolVLAよりも汎化性が見える結果でした。 検証②：π0.5のフルチューニングとVLMフリーズの違い π0.5のファインチューニングにおいてモデル全体をチューニングする方法と、VLM部分をフリーズしてチューニングする方法を比較しました。 VLM部分をフリーズすることで、学習対象のパラメーターが減り、GPUメモリ使用量や学習時間での効率化が期待できます。 学習時のStep数は全て30kと固定して比較しています。 精度の比較結果 左のフルチューニングの結果に対して、右のVLMフリーズの結果では紫ボールを除き精度が半分以下になりました。 フルチューニングとVLMフリーズ時のGPUメモリ使用量の比較 VLMフリーズによりVRAM使用量が1/3弱まで抑えられてます。 学習時の学習曲線の比較 lossの推移を見ると、VLMフリーズでも学習自体は進んでいますが緑色のフルチューニングに対して、紫色のVLMフリーズは30kのstepではlossが下がりきっていないように見えます。 アクションに関係ないVLM層であれば大きな影響がないことを期待しましたが、今回の検証においては結果としてVLMフリーズにより学習時のVRAMの使用量は大きく下げられるが、タスク実行精度は半減程度まで低下となりました。VLM層の学習もモデル実行精度への影響が大きいと言える結果となりました。 ただし毎回π0.5をフルチューニングするには必要なGPU基盤のコストが高いため、コスパ良くする策を考えたいところです。 例えば一定のフルチューニング後のモデルについてはVLMフリーズのファインチューニングのみ行うといった方法も検証の余地があると考えてます。 検証③：π0.5のチューニングStep数による違い 最後にπ0.5のチューニングStep数を30kから90kに増やした場合の実機動作を比較しました。 VLAの学習では、lossが下がっているからといって必ずしも実機の動作精度が上がるとは限りません。 そこで今回は、学習途中のモデルも使いながら、Step数によって実機動作がどのように変わるかを確認しました。 学習済みの物体・配置では30k時点で既に高い成功率を示しており、90kでも大きな変化はありませんでした。 一方、学習時と異なる物体配置や未学習の緑キューブに対しては90kで成功率が向上しており、一定の汎化性能の改善が見られました。これは、学習済みの動作パターンを未学習物体へ適用する能力が改善した可能性を示しています。 一方、未学習の紫キューブを指定した場合、一部の配置でロボットが動作しなくなる現象も見られました。 Step数の増加は汎化性能を一様に改善するわけではなく、物体・配置・言語指示の組み合わせによって挙動が変化することが分かります。 今回の結果では、30k時点で基本タスクの成功率が飽和していたため、step数増加の効果は主に位置条件の汎化性で評価しました。 逆により少ないstep数でもタスク精度が出せる可能性もあり、学習コストを減らすためにもタスクの成功率と未学習条件への汎化性能を両立できるStep数を見極めが重要だと感じます。 6.番外編：LeRobotバージョン違いによるハマったこと 今回の検証で最もハマったのが、LeRobotのバージョン違いによるアクション値の扱いです。 データ取得時はLeRobot v0.4.1、ファインチューニングと実行時はLeRobot v0.5.1を使いました。 データ取得時の環境では、データセット上のアクションは各モーターのキャリブレーション範囲に対する移動量の％として扱われていました。一方で、LeRobot v0.5.1の実行環境では、デフォルトでVLAの出力を角度値として扱う挙動になっていました。 この違いにより、モデル自体はある程度それらしいアクションを出しているにもかかわらず、実機側では意図した角度・移動量とずれてしまい、精度が大きく落ちる状態になっていました。 厄介だったのは、 それでも位置によってはある程度掴めてしまったこと です。 完全に動かないのであれば設定ミスを疑いやすいのですが、今回は「一部の条件では掴めるが、全体として精度が低い」という見え方でした。そのため、最初はファインチューニングのミスやデータ取得ミス、データ量不足、、、など色々と考え、無駄な検証を多く実施してしまうこととなりました。 今回の教訓としてLerobotはバージョン変更により細かい仕様が変わることなどがあるため、設計の理解やコード自体の確認が改めて重要であることを認識しました。 7.まとめ 今回の検証では、SO-ARM101とLeRobot環境でπ0.5を動かし、SmolVLAとの比較や、ファインチューニングの条件による違いを確認しました。 π0.5ではSmolVLAよりも物体の位置変化や学習データにない色への対応に汎化の兆しが見られ、VLAモデルの進化を感じる結果となりました。一方で、VLMフリーズや学習Step数の変更が実機の動作に与える影響は一様ではなく、モデルの大きさや学習量だけでは判断できない難しさもありました。 改めて感じたのは、VLAは実機で動かしてみないと分からないことが多い技術領域だということです。 特に今回のLeRobotのバージョン違いのように、設定に問題があっても「なんとなく動いてしまう」ことがあり、それがかえって原因の切り分けを難しくします。うまく動かない理由がモデルにあるのか、データにあるのか、制御環境にあるのかは、学習時の学習曲線では切り分けられないことも多いです。 データセット・モデル・制御実行環境を一体で確認しながら、実機の振る舞いから仮説を立てて再検証を繰り返すことが求められます。大変ではありますが、こういった泥臭さがフィジカルAIの面白さでもあると感じています。 また、 Skild AIのS1 や GeneralistのGEN-1.5 など、1回から少数の手本でタスクに対応する、ワンショット・フューショット学習の成果も発表されています。 基盤モデルの事前学習には引き続き大量のデータが重要ですが、利用する側がタスクごとにデータを集め、ファインチューニングを繰り返すという取り組み方は変わっていくかもしれません。今回のようにタスクごとにデータを収集してファインチューニングする現在のアプローチから、少数の手本で素早く現場に適応できる方向へ、VLAの実用化が進むことを期待しています。 イノラボでは、今回のような小型アームでの検証に加えて、双腕型の協働ロボットも導入し、より本格的なVLA実証を進めています。 今後もこうした技術の進化を追いながら、自分たちの環境で実際に動かし、その可能性と課題を確かめていきたいと思います。 引き続き、実機で試したからこそ分かったことを発信していきます。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @okuno_takahiro レビュー： @azeta.takuya （ Shodo で執筆されました ）

XI本部AIDC所属の佐藤です 本記事は以下の内容をまとめています FastAPIの要素技術であるイベントループ方式の理解 非同期関数内で同期関数を定義したことによる障害発生記録 同期を非同期にするときの考え方 私はそもそもイベントループ方式でのリクエスト処理とスレッドベース方式の違いについて、正確に理解できていなかったので自分のインプットと応用した記録を残そうと思い本記事を書いています イベントループ方式とは何か 従来はプロセス/スレッドがリクエストに対して割り当てられ、そのリクエストが完了するまでそのプロセス/スレッドは占有され続けるという方式が一般的でした 例として店員と客で示すと以下のような画像のイメージです この方式では客（リクエスト）が増えた際に店員（プロセス/スレッド）が増えて店（サーバー）が限界に達します この問題を C10k問題 といいます OSの制約により2 15 -1以上のプロセス生成が出来なくなり、新規接続を待つことになる問題です これを解消するためにメインの店員（スレッド）だけで客（リクエスト）の注文だけを取って非同期で処理するのがイベントループです このイベントループでは客（リクエスト）の注文を取ったら準備ができるまで他の客の注文を受けます この店員（スレッド）はとにかく注文を取ることに集中できるようになります ※厳密には注文とその周辺の非Blockingな進行 じゃあ注文の処理はどうするのかということですが、それは店員が気にしなくていいバックヤード（OS）に移譲されます 例えば外部リクエストをしていたとするとそのソケットを監視するタスクをOSに委ねます このソケットが今読める状態になったというOSの通知で再度店員（スレッド）が客（リクエスト）に商品（レスポンス）を返すことができます コラム（小さいイベントループの実装） 下記のPython（mini_epoll_loop.py）を Python3 mini_epoll_loop.pyで実行します。（Linux環境） #!/usr/bin/env python3 from __future__ import annotations import select import socket HOST = "127.0.0.1" PORT = 8765 def main() -> None: # --- 1. 受付用ソケットを作る（listen socket）--- server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((HOST, PORT)) server.listen(16) # ブロッキング禁止: accept / recv が来るまでスレッドを固めない server.setblocking(False) server_fd = server.fileno() print(f"[boot] listen on {HOST}:{PORT}") print(f"[boot] server socket の fd = {server_fd}") # --- 2. epoll インスタンスを作る（監視係）--- epoll = select.epoll() # 受付ソケットは「接続が来たら読める」扱いなので EPOLLIN を監視 epoll.register(server_fd, select.EPOLLIN) # fd → socket オブジェクトの対応表（番号から実体を辿るため） fd_to_socket: dict[int, socket.socket] = {server_fd: server} # クライアントごとに「まだ送りきれていない返信」を溜める pending_out: dict[int, bytes] = {} print("[loop] epoll 待ち受け開始（Ctrl+C で終了）") try: while True: # --- 3. イベントが来るまで待つ（ここがイベントループの心臓）--- # timeout=-1: 何か起きるまで寝る。起きてもスレッドは「監視」だけして、 # 各接続の待ちで固まらない。 events = epoll.poll(timeout=-1) for fd, event in events: sock = fd_to_socket[fd] # --- 4a. 受付ソケットが「読める」= 新しい接続が来た --- if fd == server_fd and event & select.EPOLLIN: client, addr = server.accept() client.setblocking(False) client_fd = client.fileno() fd_to_socket[client_fd] = client pending_out[client_fd] = b"" # クライアントは「データが来たら読む」だけまず登録 epoll.register(client_fd, select.EPOLLIN) print(f"[accept] {addr} → client fd={client_fd}") continue # --- 4b. クライアントからデータが届いた --- if event & select.EPOLLIN: data = sock.recv(1024) if not data: # 相手が切断 print(f"[close] fd={fd} (peer closed)") epoll.unregister(fd) sock.close() del fd_to_socket[fd] pending_out.pop(fd, None) continue print(f"[recv] fd={fd} {data!r}") # エコー: 受け取った内容を返信キューへ pending_out[fd] += data # 書き込み可能も監視する（送信バッファに空きができたら書く） epoll.modify(fd, select.EPOLLIN | select.EPOLLOUT) # --- 4c. ソケットが「書ける」= 返信を送れる --- if event & select.EPOLLOUT: out = pending_out.get(fd, b"") if out: sent = sock.send(out) pending_out[fd] = out[sent:] print(f"[send] fd={fd} sent={sent} bytes") # 送りきったら書き込み監視は外す（読み込みだけ残す） if not pending_out.get(fd): epoll.modify(fd, select.EPOLLIN) # --- 4d. エラー / 切断系 --- if event & (select.EPOLLERR | select.EPOLLHUP): print(f"[error/hup] fd={fd}") epoll.unregister(fd) sock.close() del fd_to_socket[fd] pending_out.pop(fd, None) except KeyboardInterrupt: print("\n[boot] bye") finally: epoll.unregister(server_fd) epoll.close() server.close() if __name__ == "__main__": main() 全体の流れは4段です。 受付ソケットを用意 8765 番で待ち受け。setblocking(False) で、接続やデータが来るまでスレッドをとめない epoll に登録受付ソケットの fd を EPOLLIN（読める／接続が来た）で監視。「何か起きたら教えて」と OS に頼む epoll.poll() イベントが来るまで待機し来たら「どの fd で何が起きたか」のリストが返る。ここで複数接続をまとめて処理する。 小さいエコーサーバーでソケットの監視をしていることを実感できます 別のターミナルでnc 127.0.0.1 8765を実行し、入力待ちになるので適当な文字を入力してEnterを押せば以下のような表示になります [boot] listen on 127.0.0.1:8765 [boot] server socket の fd = 3 [loop] epoll 待ち受け開始（Ctrl+C で終了） [accept] ('127.0.0.1', 33386) → client fd=5 [recv] fd=5 b'demo1\n' [send] fd=5 sent=6 bytes [recv] fd=5 b'demo2\n' [send] fd=5 sent=6 bytes [recv] fd=5 b'demo3\n' [send] fd=5 sent=6 bytes [recv] fd=5 b'demo4\n' [send] fd=5 sent=6 bytes [recv] fd=5 b'demo5\n' [send] fd=5 sent=6 bytes それぞれファイルディスクリプタを読み取って読める状態になると対応する処理が実行されていることが分かります。 イベントループで非同期関数の中に同期処理を書くことによる障害発生 覚知から暫定対応まで それではこのイベントループの方式で実装の問題によって発生した障害記録を紹介します。 覚知はALBの5xxエラーが増加していることからです。 次にECSのhealth checkパスの失敗によりタスクが落ちていることを確認しました。 この時のhealth checkを返すことができない原因が、長いSSEの通信を同期処理で行っておりメインのスレッドがブロックされていることを確認しました 暫定対応としてFastAPIのworker数を増加させ、worker数分のタスクに割り当てるスペックアップを実施しました。 ※余談ですが、worker数を増やすことは全てのスレッドが閉塞する事象の余事象の確率でサービス継続できるだけなので根本的な解決策にはなりません。この時は最もクイックに対応可能な手段として選択しました。例えばhealth checkのパスに最小のhttpサーバーを別プロセス立てすることでliveness checkとしてのパスを割り当て対応することも選択肢として考えていました。これはタスクが生きていることをベースにサービスを継続しますが、FastAPI自体がreadyであるかどうかの情報が抜け落ちるのでこれも対応としては完全ではないですね。 恒久対応 ここまでが一時的な回避でしたが、根本原因は長いSSEの通信を非同期関数の中で同期処理として記載していたことです。 これを解消する改修を恒久対応として実施しました。 まずは問題になったものを簡単にしたコードのサンプルを記載します。 仮の同期処理しかないライブラリのサンプルを提示します。 class LegacyStreamClient: """同期APIしか提供しないストリーミングクライアント""" def stream(self, prompt: str, chunks: int = 20, interval: float = 0.5) -> Iterator[str]: for i in range(chunks): # 上流からのレスポンス待ち（ブロッキングI/O） time.sleep(interval) yield f"{prompt} - chunk {i + 1}/{chunks}" このstream関数は同期的に処理を行うライブラリの関数だと考えてください。 async def generate_events(prompt: str) -> AsyncIterator[str]: # NG: async def の中で、同期専用ライブラリのブロッキング処理を直接回している。 for chunk in client.stream(prompt): yield f"data: {chunk}\n\n" yield "data: [DONE]\n\n" @app.get("/stream") async def stream(prompt: str = "hello"): return StreamingResponse(generate_events(prompt), media_type="text/event-stream") このコードは非同期関数の中で同期処理のstream関数を呼び出しています。 これが実際に動くと以下のようになります。 通常I/Oが発生する際にはOSに移譲できていたにも関わらず、1人の処理が注文（非同期処理）だけのふりをして、用事（同期処理）まで受付で済ませようとしているイメージです。 ここで後ろに控えていたのがhealth checkの処理でレスポンスを返せずunhealthyなタスクとしてECSが落としました。 これを修正する際には以下のような実装に切り替えました。 def generate_events_sync(prompt: str) -> Iterator[str]: #この関数はワーカースレッドで実行する for chunk in client.stream(prompt): yield f"data: {chunk}\n\n" yield "data: [DONE]\n\n" _SENTINEL = object() # 同名で非同期関数を作成 async def generate_events(prompt: str) -> AsyncIterator[str]: it = generate_events_sync(prompt) while True: # generate_events_sync(=it)がスレッドに逃がされて非同期に処理できるようになっている event = await asyncio.to_thread(next, it, _SENTINEL) if event is _SENTINEL: break yield event @app.get("/stream") async def stream(prompt: str = "hello"): # 呼び出し側は変更なし return StreamingResponse(generate_events(prompt), media_type="text/event-stream") 非同期の薄いラッパー関数を定義して、その中で同期関数をスレッドに逃がして呼び出すように修正します。 この同期関数は受付とは別のスレッドで実行されるため、メインのイベントループをブロックすることなく処理を継続することができます。 非同期の関数は同名で定義しなおしているので、既存のコードに影響を与えることなく利用することができます。 この修正により恒久対応を完了することができました。 同期を非同期にするときの考え方 今回は同期でしか書けないライブラリの使用だったため、スレッドに逃がす回避策を活用しました。 同様の問題に直面したら以下の順番で考えるのがいいのではないかと思います。 振り分け 非同期化対応の手段がないか探す。ライブラリにはasyncクライアントが存在することが多い。 1がなければI/Oの処理かCPU処理かを考える I/O処理の場合 全体で使用しうるスレッド数が上限に触れないかをチェックする スレッドセーフな処理かをチェックする 中断時の処理を考える ※補足 スレッド数は今回のasyncio.to_threadであればCPUの数+4で導出されるので、どのくらいの処理まで逃がせるのかは頭に入れておく必要があります 上記の3点を考えたうえで、to_threadで別のスレッドプールに処理を逃がすのがいいと思います CPU処理の場合 現状のサーバーのメトリクスをチェックする プロセス/workerを増やした際の見込みスペックを算出する 上記の2点を考えたうえで、プロセス/workerを増加させますがこれらはスペックアップが必要になる場合の多い緩和策に過ぎないことは意識しておくべきです。 まとめ AIも賢くなってここら辺の実装もできちゃいますが、小さい範囲の実装等でコンテキストが十分にわたってないとその範囲で動くコードを出力することがあります。 最近はAIの出力を理解するので精一杯なところもあります。 ただ、このスピード感に飲まれずに気になったところを深堀りして理解することが若手のエンジニアがAIの出力の良し悪しを判断するための足場になると思ってます。 結局、エンジニアのあり方の根本は変わってないのかもしれないですね。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sato.yu レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

エンタープライズ会計ソリューション本部の三上です。 先日、クロスイノベーション本部の大岡叡さんが主催する「25卒合同AWS勉強会 #4」に参加してきましたので、その様子をお届けします！ 私は業務上AWSに触れる機会が限られているため、最新のAWS活用事例や技術動向を学ぶことを目的に参加しました。 生成AIやエージェント開発など、現在注目を集めるテーマについて実践的な知見に触れることができ、大変有意義な機会となりました。 イベント概要 イベント内容 発表内容の紹介 1. Organizations+Control Towerでハッカソン環境をつくる 2. "LLMをAIで呼ぶだけ"では終わらなかったAWS AI導入 3. Databricksを使ってS3のデータを分析してみる 4. AgentCoreを使ったエージェント開発 5. AWS Blocksで爆速アプリ開発しよう！ 6. AWS Codeシリーズを使って、CI/CDを実現しましょう まとめ イベント概要 開催日時：2026/9/18(金) 開催場所：NEC玉川事業場 NEC Innovation Park 開催形態：ハイブリッド(対面+オンライン) 参加者：38名 イベント内容 今回は合計6名が登壇し、AWSに関係するテーマで15分間ずつ(発表10分+質疑5分)発表しました。 当日のタイムスケジュールは以下のとおりです。 時間 内容 所属 発表者 発表テーマ 19:00-19:05 開会 電通総研 河岸 歩希 - 19:05-19:20 発表(1) NECソリューションイノベータ 今井 武蔵 Organizations+Control Towerでハッカソン環境をつくる 19:20-19:35 発表(2) 電通総研 花田 涼介 "LLMをAIで呼ぶだけ"では終わらなかったAWS AI導入 19:35-19:50 発表(3) ウフル 高橋 尚 Databricksを使ってS3のデータを分析してみる 19:50-20:10 休憩 - - - 20:10-20:25 発表(4) - 片山 歩希 AgentCoreを使ったエージェント開発 20:25-20:40 発表(5) - 川崎 翔太 AWS Blocksで爆速アプリ開発しよう！ 20:40-20:55 発表(6) - 三与木 輝 AWS Codeシリーズを使って、CI/CDを実現しましょう 20:55-21:00 閉会 電通総研 大岡叡 - 発表内容の紹介 AWSの運用基盤から生成AI、データ分析、エージェント開発まで、多彩なテーマが取り上げられましたのでご紹介します。 1. Organizations+Control Towerでハッカソン環境をつくる AWS OrganizationsとControl Towerを活用し、AWSハッカソン向けの検証環境を構築・運用する方法をご紹介いただきました。チームごとのアカウントに対してSSOによる認証統合やガードレールによる統制を適用し、参加者が安全に利用できる環境を少ない運用負荷で実現していました。 2. "LLMをAIで呼ぶだけ"では終わらなかったAWS AI導入 Amazon Bedrockを利用した社内ドキュメント検索チャットボットの構築経験をもとに、セキュリティ、コスト、レイテンシの3つの課題を改善した方法について解説していただきました。それぞれの課題におけるパラメータが多く、多角的な視点から試行錯誤を重ね、検証を繰り返しながら改善を進められていた点が印象的でした。 3. Databricksを使ってS3のデータを分析してみる Databricksを用いてデータ分析基盤を構築する方法を紹介していただきました。クラウド型のコンタクトセンターサービスであるAmazon Connectの通話データを分析するためのデータ基盤について、AWSサービスによる構成とDatabricks構成を比較しながら、それぞれのサービスの特徴をご説明いただきました。 4. AgentCoreを使ったエージェント開発 Amazon Bedrock AgentCore RuntimeをCDKで構築する際の注意点についてご紹介いただきました。CDK Bootstrapで生成されるQualifierを用いたECRリポジトリ管理の仕組みや、複数プロジェクトで発生し得る問題とその回避策など、実際に触ってみないと気付きにくい知見が共有されました。 5. AWS Blocksで爆速アプリ開発しよう！ 2026年6月にパブリックプレビューとなったAWS Blocksについて解説していただきました。TypeScriptでアプリケーションコードを書くことでAWSインフラまで自動生成できる仕組みが紹介され、Infrastructure From Codeのサービスとして非常に興味深い内容でした。また、簡単に検証ができる理由や拡張性の高さについてもご説明いただきました。 6. AWS Codeシリーズを使って、CI/CDを実現しましょう AWS CodeシリーズのAWS CodeCommit、CodeConnections、CodeBuild、CodeDeploy、CodePipelineを用いてCI/CDパイプラインを構築する方法についてご説明いただきました。CodeBuild、CodeDeployで使用するymlファイルであるbuildspec.ymlやappspec.ymlの具体例も交えながら説明していただき、各サービスの役割や処理の流れを具体的・体系的に理解することができました。 まとめ 今回はAWSの運用基盤、生成AI、データ分析、エージェント開発、アプリケーション開発、CI/CDと、非常に幅広いテーマの発表を聞くことができました。どの発表も実際の検証や開発を通じて得られた実践的な知見に基づくものであり、AWS活用の可能性や技術進化のスピードを改めて実感する機会となりました。今後の業務や自己研鑽にも活かしていきたいと感じる、大変刺激的な勉強会でした。 発表していただいた皆様、そして運営していただいた大岡さんをはじめとする関係者の皆様、ありがとうございました！ 次回のAWS勉強会も楽しみにしています！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @mikami.ryosuke レビュー： @kinjo.ryuki （ Shodo で執筆されました ）

エンタープライズ会計ソリューション本部の三上です。 先日、クロスイノベーション本部の大岡叡さんが主催する「25卒合同AWS勉強会 #4」に参加してきましたので、その様子をお届けします！ 私は業務上AWSに触れる機会が限られているため、最新のAWS活用事例や技術動向を学ぶことを目的に参加しました。 生成AIやエージェント開発など、現在注目を集めるテーマについて実践的な知見に触れることができ、大変有意義な機会となりました。 イベント概要 イベント内容 発表内容の紹介 1. Organizations+Control Towerでハッカソン環境をつくる 2. "LLMをAIで呼ぶだけ"では終わらなかったAWS AI導入 3. Databricksを使ってS3のデータを分析してみる 4. AgentCoreを使ったエージェント開発 5. AWS Blocksで爆速アプリ開発しよう！ 6. AWS Codeシリーズを使って、CI/CDを実現しましょう まとめ イベント概要 開催日時：2026/9/18(金) 開催場所：NEC玉川事業場 NEC Innovation Park 開催形態：ハイブリッド(対面+オンライン) 参加者：38名 イベント内容 今回は合計6名が登壇し、AWSに関係するテーマで15分間ずつ(発表10分+質疑5分)発表しました。 当日のタイムスケジュールは以下のとおりです。 時間 内容 所属 発表者 発表テーマ 19:00-19:05 開会 電通総研 河岸 歩希 - 19:05-19:20 発表(1) NECソリューションイノベータ 今井 武蔵 Organizations+Control Towerでハッカソン環境をつくる 19:20-19:35 発表(2) 電通総研 花田 涼介 "LLMをAIで呼ぶだけ"では終わらなかったAWS AI導入 19:35-19:50 発表(3) ウフル 高橋 尚 Databricksを使ってS3のデータを分析してみる 19:50-20:10 休憩 - - - 20:10-20:25 発表(4) - 片山 歩希 AgentCoreを使ったエージェント開発 20:25-20:40 発表(5) - 川崎 翔太 AWS Blocksで爆速アプリ開発しよう！ 20:40-20:55 発表(6) - 三与木 輝 AWS Codeシリーズを使って、CI/CDを実現しましょう 20:55-21:00 閉会 電通総研 大岡叡 - 発表内容の紹介 AWSの運用基盤から生成AI、データ分析、エージェント開発まで、多彩なテーマが取り上げられましたのでご紹介します。 1. Organizations+Control Towerでハッカソン環境をつくる AWS OrganizationsとControl Towerを活用し、AWSハッカソン向けの検証環境を構築・運用する方法をご紹介いただきました。チームごとのアカウントに対してSSOによる認証統合やガードレールによる統制を適用し、参加者が安全に利用できる環境を少ない運用負荷で実現していました。 2. "LLMをAIで呼ぶだけ"では終わらなかったAWS AI導入 Amazon Bedrockを利用した社内ドキュメント検索チャットボットの構築経験をもとに、セキュリティ、コスト、レイテンシの3つの課題を改善した方法について解説していただきました。それぞれの課題におけるパラメータが多く、多角的な視点から試行錯誤を重ね、検証を繰り返しながら改善を進められていた点が印象的でした。 3. Databricksを使ってS3のデータを分析してみる Databricksを用いてデータ分析基盤を構築する方法を紹介していただきました。クラウド型のコンタクトセンターサービスであるAmazon Connectの通話データを分析するためのデータ基盤について、AWSサービスによる構成とDatabricks構成を比較しながら、それぞれのサービスの特徴をご説明いただきました。 4. AgentCoreを使ったエージェント開発 Amazon Bedrock AgentCore RuntimeをCDKで構築する際の注意点についてご紹介いただきました。CDK Bootstrapで生成されるQualifierを用いたECRリポジトリ管理の仕組みや、複数プロジェクトで発生し得る問題とその回避策など、実際に触ってみないと気付きにくい知見が共有されました。 5. AWS Blocksで爆速アプリ開発しよう！ 2026年6月にパブリックプレビューとなったAWS Blocksについて解説していただきました。TypeScriptでアプリケーションコードを書くことでAWSインフラまで自動生成できる仕組みが紹介され、Infrastructure From Codeのサービスとして非常に興味深い内容でした。また、簡単に検証ができる理由や拡張性の高さについてもご説明いただきました。 6. AWS Codeシリーズを使って、CI/CDを実現しましょう AWS CodeシリーズのAWS CodeCommit、CodeConnections、CodeBuild、CodeDeploy、CodePipelineを用いてCI/CDパイプラインを構築する方法についてご説明いただきました。CodeBuild、CodeDeployで使用するymlファイルであるbuildspec.ymlやappspec.ymlの具体例も交えながら説明していただき、各サービスの役割や処理の流れを具体的・体系的に理解することができました。 まとめ 今回はAWSの運用基盤、生成AI、データ分析、エージェント開発、アプリケーション開発、CI/CDと、非常に幅広いテーマの発表を聞くことができました。どの発表も実際の検証や開発を通じて得られた実践的な知見に基づくものであり、AWS活用の可能性や技術進化のスピードを改めて実感する機会となりました。今後の業務や自己研鑽にも活かしていきたいと感じる、大変刺激的な勉強会でした。 発表していただいた皆様、そして運営していただいた大岡さんをはじめとする関係者の皆様、ありがとうございました！ 次回のAWS勉強会も楽しみにしています！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @mikami.ryosuke レビュー： @kinjo.ryuki （ Shodo で執筆されました ）

こんにちは、事業開発室の里中裕輔です。 本記事では、LayerXさんと共同で開催した「AIエージェント設計勉強会 〜自己改善、検索編〜」 についてレポートします。 勉強会の概要 本勉強会は、LayerXさんと電通総研が共同で開催している、AIエージェントに関するエンジニア向けの勉強会イベントです。その第3回目として、2026年09月15日（火）に、自己改善、検索に関する勉強会を開催しました。 生成AIの登場から数年経ち、プロダクトの機能にAIエージェントを組み込む事例が増えています。さらに直近ではAIエージェントを活用する範囲が広がり、人が行っていたプロダクト改善作業の一部を、AIエージェントに任せる取り組みも増えてきています。 今回の勉強会では、LayerX と 電通総研が AIエージェント設計の最新動向についてお伝えし、AIエージェントを継続的に動かすための設計・実装・運用の知見を共有しました。 会場はFINOLABのイベントスペースで、50人程度の方に参加していただきました。 勉強会の内容としては以下のとおりです。 ・株式会社LayerX『堤 大貴』さん： 「AIエージェントの自己改善をどう設計するか」 ・株式会社電通総研『里中 裕輔』： 「なぜ検索が成果物の質の上限を決めるのか」 ・懇親会 AIエージェントの自己改善をどう設計するか 堤さんからは、従来人間が手作業で構築していたAI WorkflowをCoding Agentを用いて構築する方法についてお話がありました。 Agentに改善を任せると、精度が90%程度で停滞する事例が共有され、その原因として設計そのものを疑う改善案が出てこない課題が示されました。既存研究でも指摘されている「Anchoring Bias」に対して、ハーネスの設計で解決することを試み、その内容が共有されました。 Training Data（実行ログから知識抽出）、Optimizer（編集量の制御と改善の検証）、Search Strategy（複数候補による局所最適化の回避）、Evaluation（評価の品質）の4つの観点をハーネス上で組み合わせることで解決する知見をお話ししていただきました。詳細は、下記の発表資料をご覧ください。 https://speakerdeck.com/22mi/how-to-design-self-improvement-for-ai-agents 発表後の質疑では、「改善ループを構築するにあたり、ビジネスアナリシスやプロセスマイニングが重要なのではないか」というお話や「技術開発の内容をプロダクトに反映するために、顧客データをどのような扱っているのか」についての質問がありました。 なぜ検索が成果物の質の上限を決めるのか 私、里中からは Deep Searchシステムにおける、探索と検索の重要性についてお話をさせていただきました。 Deep Searchシステムをオープンウェイトなモデルを用いて構築するにあたり、探索や検索を工夫することが、精度向上の一つの方法であることをお話ししました。 電通総研が過去の案件や、学会のコンペティションで実際に試した方法の中で、クエリ（検索語の多様化）や適切なリランキング、出典追跡などの手法が、検索結果を改善する効果が高かったことを共有しました。発表スライドはこちらで公開しているので、興味のある方はご覧ください。 https://speakerdeck.com/hisanoriozaki/naze-kensaku-ga-seikabutsu-no-shitsu-no-jougen-o-kimeru-no-ka 発表後の質疑では、「プロンプトにHowが含まれていた場合に取り除くことは有用なのか」というお話や「Whyを書いてみると精度が上がるのではないか」などの議論が行われました。 懇親会 懇親会も多くの方に残っていただき、発表内容に関する質疑や広くAIについてのディスカッションができました。 電通総研のメンバーとしては発表内容に関する話題を中心に会話しておりましたが、「AIエージェントを構築するために、どのフレームワークを使ったほう良いか」であったり「非IT企業の非エンジニアの方々にLLMやエージェントを使ってもらうための、コスト政策やセキュリティについて」など、AIエージェントの構築・運用に関する質問も数多く見受けられました。 私自身としても、多様な視点で会話することができ、有意義な懇親会だったと感じております。 まとめ 今回は、LayerXさんと電通総研が共同で開催した 「AIエージェント設計勉強会 〜自己改善、検索編〜」 についてレポートしました。 今回の勉強会で両者の発表に共通した話題は、「人間の役割は、業務上の正しさをLLMが評価できる指標に落とし込むこと」という話でした。LayerXさんの発表にあったAI Workflowを自己改善する仕組みも、評価を正しく行えなければ継続して改善できる仕組みにすることは困難であるというお話でした。我々、電通総研の発表も、「どういう検索結果を出せれば成功なのか」を人間が定義しないといけないというお話をさせていただきました。LLMやAIエージェントが日進月歩で高性能になってきていますが、業務への活用においては、仕事を任せる人間が業務上の正しさを落とし込む必要があることを実感しました。 電通総研は、引き続きこのような勉強会を開催する予定ですので、興味ある方はぜひご参加ください。 https://engineersguild.peatix.com/ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @satonaka.yusuke レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

1. はじめに こんにちは。電通総研の武田嵩史（たかふみ）です。 今回は、AWSが公開している Engineering Development Hub（EDH） を実際にデプロイして触ってみたので、その内容を紹介します。 EDHは以前 Scale-Out Computing on AWS（SOCA） という名称で公開されていたソリューションで、2026年4月からEngineering Development Hubという名称になりました。 AWSにはHPC環境を構築するための選択肢として、 AWS Batch や AWS ParallelCluster 、 AWS Parallel Computing Service（AWS PCS） などがあります。 そんな中でEDHはどのような位置付けなのか。 また、実際にデプロイするとどのような環境ができて、ユーザーはどのように利用するのか。 今回は実際にEDHを構築しながら確認してみました。 本記事は以下の流れとなっております。 はじめに AWSのHPC関連サービスとEDH EDHをデプロイしてみた EDHの基本機能を触ってみる 実際に触ってみた感想 2. AWSのHPC関連サービスとEDH まず、EDHについて紹介する前に、AWSでHPC環境を構築する際に利用できる代表的なサービス・ソリューションを簡単に整理してみます。 2.1 AWS Batch AWS Batch は、AWS上でバッチワークロードを実行するためのフルマネージドサービスです。 ジョブをキューへ投入すると、必要なコンピュートリソースをAWS Batchが自動的にプロビジョニングし、ジョブを実行します。 （引用元） AWS Batch (BlackBelt資料) EC2やAWS Fargateなどを計算リソースとして利用でき、利用者側でバッチ処理基盤そのものを構築・管理する負担を減らせる点が特徴です。 一方で、AWS Batchは独自スケジューラーを使ったコンテナ中心のジョブ実行基盤です。 そのため、 既存のHPCクラスタをそのままクラウドへ移行したい Slurmなど既存のジョブスケジューラを使いたい SSHログインして従来型のHPCクラスタとして利用したい といったケースでは、AWS ParallelClusterやAWS PCSなどが選択肢となってきます。 2.2 AWS ParallelCluster AWS ParallelCluster は、AWS上にHPCクラスタを構築・管理するオープンソースのツールです。 設定ファイルを定義してクラスタを作成すると、 Head Node Compute Node ジョブスケジューラ（Slurm） 共有ファイルシステム Auto Scaling など、HPCクラスタに必要なリソースをまとめて構築できます。 （引用元） AWS ParallelClusterではじめるクラウドHPC (BlackBelt資料) （ParallelClusterUIというGUIから環境を構築できる仕組みもあります。） ParallelClusterでは、主にSlurmを利用したHPCクラスタを比較的簡単に構築できます。 一方、IaaS基盤としての構築となるため、AWS全体の知識、NW・サーバに関する知識が必要となります。 オンプレミスHPCに近い構成をAWS上へ構築できるため、 「クラウド上に一般的なHPCクラスタを作りたい」 「商用（市販）ソフトウェアを使いたい」 というケースに適したサービスです。 2.3 AWS Parallel Computing Service（AWS PCS） AWS Parallel Computing Service（AWS PCS） は、Slurmを利用したHPC環境をAWS上で構築するためのマネージドサービスです。 AWS PCSではSlurmのコントロールプレーンをAWS側で管理し、EC2、ストレージ、ネットワークなどのAWSサービスと組み合わせてHPCクラスタを構築します。 ParallelClusterと比較すると、Slurm/クラスタ管理ノードの管理負荷をAWS側へ寄せられる点が大きな特徴です。 そのため、 「Slurmを使いたいが、スケジューラを含めたクラスタ管理の負担をできるだけ減らしたい」 「商用（市販）ソフトウェアを使いたい」 という場合に検討しやすいサービスです。 2.4 Engineering Development Hub（EDH） そして今回紹介するのが Engineering Development Hub（EDH） です。 EDHは、AWS BatchやAWS PCSのようなマネージドサービスではなく、AWS ParallelClusterに近しく、AWSサービスを組み合わせたHPCクラスタ環境構築のサービスです。 こちらもAWS ParallelClusterと同様に オープンソースソリューション です。 以前は Scale-Out Computing on AWS（SOCA） という名称で提供されていましたが、2026年4月にEngineering Development Hubへリブランディングされ、名称変更されました。 EDHとAWS ParallelClusterの違いは、EDHはHPCクラスタそのものだけではなく、その周辺に必要となる機能まで含めて構築できる点です。 EDHの主要な機能を以下に紹介します。 項目 EDHで提供される機能 EDH特有 HPCジョブ管理 OpenPBS、Slurm、IBM LSFなどを利用 － Compute ジョブに応じたEC2の動的プロビジョニング － GUI環境 Amazon DCVを利用したLinux / Windowsデスクトップ環境の利用/管理 － Webポータル ジョブ、デスクトップ、ファイルなどの管理 〇 認証 OpenLDAP / Microsoft Active Directory 〇 ストレージ EFS、FSx for Lustre、FSx for NetApp ONTAP － ライセンス FlexLMなどのネットワークライセンスとの連携 〇 コスト AWS Budgets / Cost Explorerなどとの連携 〇 分析 ジョブやクラスタ利用状況の可視化 〇 【凡例】 〇：EDH特有の機能 　 －：他AWS HPCサービスにも存在する機能 EDHはAWS ParallelClusterやPCSと異なるスケジューラー、OpenPBS、IBM LSFを扱うことができるという違いもありますが、Web UIを用いたジョブ管理やコスト管理、ジョブの利用状況可視化まで行えるものとなっております。 EDHは 「HPCクラスタ環境を作る」のみではなく、 「HPCクラスタ環境と周辺機能をまとめて作るもの」 といえます。 2.5. AWSのHPC関連サービスのまとめ まとめると以下のとおりです。 サービス 概要 主なジョブスケジューラー 計算実行基盤 AWS Batch バッチジョブを実行するための マネージドサービス 独自スケジューラー EC2, Fargate(コンテナ) AWS ParallelCluster AWS上にHPCクラスタを構築するための オープンソースツール Slurm EC2クラスタ AWS PCS Slurmを利用したHPC環境のための マネージドサービス Slurm EC2クラスタ EDH HPC環境だけでなく、Webポータルや仮想デスクトップ（VDI）なども含めたエンジニアリング環境を構築するための オープンソースツール OpenPBS, Slurm, IBM LSF EC2クラスタ では、このEDHを実際にAWS上へデプロイしていきたいと思います。 3. EDHをデプロイしてみた それでは実際にEDHをデプロイしてみます。インストールガイドは こちら 。 EDHのソースコード はGitHubで公開されています。 GitHubからソースコードをクローンしまして、EDHで用意されているインストーラを利用します。 installer/edh_installer.sh インストーラを実行すると、AWS環境やネットワーク、EDHで利用する各種設定を対話形式で指定していきます。 インストーラ画面 Python3.13が要件となるため、まずはPythonがインストールされることとなります。 Pythonインストール後、対話形式のインストーラが起動され、”デプロイするリージョン”、”新規リソース or 既存リソースを利用するのか”、”VPCのCIDRはどうするのか”、といった項目を入力します。 一通りの値を入力すると、裏側でCloudFormationが利用されてEDHに必要なAWSリソースが作成されます。 CloudFormation デプロイ後にAWS Management Consoleを確認すると、EC2をはじめ、EDHを構成するさまざまなAWSリソースが作成されていることが分かります。 EDHは1台のEC2上で動作するアプリケーションというより、複数のAWSサービスを組み合わせて1つの環境を作る構成になっています。ざっくりした構成図は以下のとおりです。（Ver.26.4.0版。 最新の構成は異なる場合がございます）。 このあたりは実際にデプロイしてみると、EDHの全体像がかなり掴みやすくなりました。 4. EDHの基本機能を触ってみる デプロイが完了したので、実際にEDHへログインしてみます。 4.1 Webポータル EDHにはWebポータルが用意されています。 ※本番環境だと証明書をインストールする必要がありますね。 ログインすると、ジョブや仮想デスクトップ、ファイルなどを管理するための画面が表示されます。 HPC環境というとSSHでログインしてコマンドを実行するイメージが強いですが、EDHではさまざまな操作をWebブラウザから行えるようになっています。 メニューを見てみると、 ファイルエクスプローラー ウェブターミナル 仮想デスクトップ 私のHPCジョブ（My HPC Jobの日本語訳だと思いますが…） クラスターメトリックス など、HPC環境を利用するための機能がメニューに並んでいます。 メニュー下部には、ユーザー管理、グループ管理など管理者メニューのようなものも並んでますね。 今回は、この中からジョブの実行と仮想デスクトップ周りを触っていきます。 4.2 ジョブの実行 それでは簡単なジョブを投入して、EDH上でジョブが実行できることを確認します。 EDHではWebポータル上からもジョブの投入が行えるため、Webポータルからジョブの実行を行ってみます。 メニューから”私のHPCジョブ”を選択します。 遷移後の画面で何もジョブが入っていないことが確認できます。 ”新しいジョブを開始する”を選択し、ジョブスクリプトを選択します。 ここで少し分かりづらいのが、ジョブスクリプトの選択方法です。 左から2つ目のEC2インスタンスのアイコンみたいなものを選択して、ジョブスクリプトを選択します。 その後、どのワークフローで実行するかを選択できますが、今回は特段アプリケーションはインストールしていないので、”Test Application”で進めていきます。アプリケーションインストールしている場合は、ここに各ワークロードを登録してユーザーに選択させるようにすることができます。 その後、ジョブを実行するために必要なパラメーターを埋める画面となるので、必要情報を入力します。 このあたりの設定詳細はEDHの管理画面からカスタマイズできるため、ユーザーと会話して必要な内容に変更する方が親切ですね。 各種条件を設定すると、ジョブ実行時にかかるマシンの費用（/1時間）を算出してくれるのは良いですね！ 解析にどのくらいのコストがかかるのかが試算出来ます。 これでジョブを実行します。 ジョブを実行すると先ほどは空だったジョブリストに投入したジョブが表示されています。 しばらくすると、ジョブを実行するためのEC2インスタンスが起動し始めました。 ジョブが実行され、完了すると計算ノードも不要になるため、自動的に削除されます。 これにより計算を実行していないときには、不必要なEC2マシンの起動が防がれ、コストの最適化が図れます。 また、ジョブスケジューラーにはOpenPBSを利用しているため、ログインノードに接続して通常のPBSと同じようにジョブを投入することもできます。（デフォルトログインノードには”SOCA"の文字が残っていますね）。 qsub test_job.sh ジョブを投入すると、Queueにジョブが登録されます。 [edhadmin@ip-10-30-76-119 ~]$ qstat Job id Name User Time Use S Queue ---------------- ---------------- ---------------- -------- - ----- 1.ip-10-30-87-225 edh_test edhadmin 0 Q normal オンプレミスのHPC環境では計算ノードをあらかじめ用意しておくことが一般的ですが、EDHではAWSの特長を活かして、必要なタイミングで計算リソースを用意できます。 このあたりの細かな仕組みについては奥が深そうなので、もう少し詳しく見る必要がありそうです。 4.3 仮想デスクトップ では、続いて仮想デスクトップに移りたいと思います。 EDHにはWebポータルから仮想デスクトップ（VDI）を作成する機能もあります。 メニューから”仮想デスクトップ”へ移ります。今回は新しく仮想デスクトップマシンを作成してみます。 ”新しい仮想デスクトップを起動する”を選択します。 ここでも起動に必要なパラメーターを設定していきます。設定し終えたら”マイデスクトップを起動”を押下します。 仮想デスクトップマシンの起動が開始されました！ 仮想デスクトップには Amazon DCV が利用されており、ブラウザやDCVクライアントからLinuxやWindows環境へ接続できます。 EC2を起動している最中に、（たしか）ユーザーデータを使用してAmazon DCVをインストールしています。 このあたりはゴールデンイメージを作成することで起動時間の短縮が図れそうですね。 仮想デスクトップマシンへも接続できました。 CAE用途で考えると、EDHのWebポータル上でプリポスト処理用のGUI環境を用意して、プリ処理を行う。出力したデータをWebポータルからHPC環境へ計算を流す、といった使い方もできそうです。 単純なHPCクラスタだけでなく、このようなユーザー環境までまとめて用意できるところがEDHの特徴だと感じました。 AWS ParallelClusterでもAmazon DCVをプリインストールするオプション選択などで仮想デスクトップ環境は準備できますが、GUIを用いてここまで柔軟に作成・管理できるのはEDHの強みではないかと思います。 5. 実際に触ってみた感想 今回初めてEDHをデプロイしてみましたが、最初に想像していたよりもかなり機能の多いソリューションでした。 触る前は、"OpenPBSにも対応したクラウドHPC構築サービス"というイメージを持っていました。 実際には、HPCクラスタだけではなく、 Webポータル 仮想デスクトップの管理・接続 ファイル管理 ユーザー管理 コスト管理 ジョブ実行管理 など、ユーザーが計算環境を利用するための機能が多数そろっています。 特にCAEのように、 プリ処理 → Solver実行 → ポスト処理 という一連の作業をクラウド上で行う環境を作る場合には、EDHをデプロイするだけでCAE環境構築ができることはかなり面白いと感じました。 一方、デフォルトでデプロイする場合、要件によっては不要な機能・サービスが作成されてしまうことがあります。機能が多くある反面、要件に従った構築を実施する場合には、綿密な設計が必要なところは注意点です。 ただ、AWSにはAWS Batch、AWS ParallelCluster、AWS PCSなどさまざまなHPC向けサービスがある中で、また少し違った位置付けのEDHが新たにリリース（正確にはリブランディング）されたのは大変嬉しいです！ 実際に業務でEDHを活用していくとなると、単純にデプロイして終わりではなく、お客様環境に合わせた構成や商用ソルバーとの連携、ユーザーが使いやすい環境へのカスタマイズなど、いろいろと考えることが出てきます。 電通総研では、これまでHPC/CAE環境をAWS上で構築してきた知見もありますので、EDHの導入を検討されている方や、AWS上でのHPC/CAE環境について気になることがありましたら、ぜひお気軽に ご相談 ください。 次回はもう少し踏み込んだ応用編も書いてみたいと思います！最後までお読みいただきありがとうございました！ 今回は以上となります。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @takeda.takafumi レビュー： @miyazaki.hirotoshi （ Shodo で執筆されました ）

1. はじめに こんにちは！電通総研の武田嵩史（たかふみ）です。 前回の「 AWS hpc8a ベンチマークレポート 第1回 」では、AMDの最新プロセッサであるTurin（AMD EPYC 9R45）を搭載した hpc8a.96xlarge を中心に、Ansys FluentとCradle MSC scFLOWのベンチマーク結果をご紹介しました。 今回は第2回ということで、前回予告していた以下2つのソルバーの結果をご紹介します！ Ansys LS-DYNA Siemens STAR-CCM+ 衝突解析系のLS-DYNA、流体解析系のSTAR-CCM+と、性質の異なる2つのソルバーでhpc8aがどのような結果を示したのか、 実行時間・コスト・コストパフォーマンス の3つの観点から見ていきたいと思います。 本記事は以下の流れとなっております。 目次 はじめに ←終了 ベンチマーク概要 Ansys LS-DYNA ベンチマーク結果 Siemens STAR-CCM+ ベンチマーク結果 おわりに 2. ベンチマーク概要 第1回の記事でもご紹介しましたが、今回のベンチマーク環境について簡単におさらいします。 2.1 ベンチマークに利用したインスタンスタイプ LS-DYNAおよびSTAR-CCM+では、以下のインスタンスタイプを比較対象としました。 Instance type Spec Cost $ (instance/h) Cost $ (core/h) hpc6id.32xlarge (Intel) CPU：Intel Xeon Ice Lake 64 cores Memory：1024GB NIC：200Gbps EFA $5.70 $0.09 r8i.96xlarge (Intel) CPU：Intel Xeon 6 Granite Rapids-AP 192 cores Memory：3072GB NIC：100Gbps EFA $26.67 $0.14 c7a.48xlarge (AMD) CPU：AMD EPYC 9R14 Genoa 192 cores Memory：384GB NIC：50Gbps EFA $9.85 $0.05 hpc7a.96xlarge (AMD) CPU：AMD EPYC 9R14 Genoa 192 cores Memory：768GB NIC：300Gbps EFA $7.20 $0.04 c8a.48xlarge (AMD) CPU：AMD EPYC 9R45 Turin 192 cores Memory：384GB NIC：75Gbps EFA $10.35 $0.06 hpc8a.96xlarge (AMD) CPU：AMD EPYC 9R45 Turin 192 cores Memory：768GB NIC：300Gbps EFA $7.92 $0.04 ※Costはオハイオリージョンでの単価です。 ※Cost $ (core/h), Cost $ (instance/h)は小数点3桁を四捨五入した小数点以下2桁で表記しています。 ※一部の並列数・インスタンスタイプではベンチマーク結果が存在しないものがあります。 ※第1回のベンチマークで実施した”m8a.48xlarge”、”c8g.48xlarge”については、リソースの都合上今回ベンチマーク実施できませんでした。 2.2 ベンチマークモデル 今回の記事（第1回も含め）で扱うベンチマークモデルは以下です。 Solver Version Benchmark Model Ansys Fluent 2025R2 f1_racecar_140m Fluent benchmark model Ansys LS-DYNA 2025R2 Car2Car LS-DYNA benchmark model Siemens STAR-CCM+ 2506.0001 Golf_140M [Original Model] Cradle MSC scFLOW 2025.1 Common Research Model 2.3 ベンチマーク実施環境と評価項目 ベンチマーク実施環境、評価項目につきましては第1回と同じになりますので、第1回の記事をご参照ください。 （参考） AWS "hpc8a" ベンチマークレポート 第1回～AWS hpc8a Benchmark Report by Dentsusoken～ 3. Ansys LS-DYNA ベンチマーク結果 ではAnsys LS-DYNAの結果です。 LS-DYNAでは、 64並列・128並列・256並列・512並列 でベンチマークを実施しました。 3.1 実行時間 ソルバー実行の経過時間比較 全ての並列数において、 hpc8a.96xlargeが最も短い実行時間 となりました。 前世代hpcインスタンスとの比較 前世代の hpc7a.96xlarge と比較すると、hpc8a.96xlargeでは以下の性能向上が確認できました。 並列数 hpc7a 実行時間 [s] hpc8a 実行時間 [s] 性能向上率 64 8,574.743 4,747.619 約45%向上 128 5,498.062 3,300.729 約40%向上 256 3,563.120 2,077.994 約42%向上 512 2,408.745 1,416.822 約41%向上 全並列数で4割前後の性能改善 となっており、今回実施したソルバーの中でも、世代更新による効果が特に大きく見えた結果です。 同世代Turinのコンピューティング最適化インスタンスとの比較 同じTurinを搭載する c8a.48xlarge と比較しても、hpc8a.96xlargeは全並列数で高速でした。 並列数 c8a 実行時間 [s] hpc8a 実行時間 [s] 性能向上率 64 6,655.073 4,747.619 約29%向上 128 4,863.415 3,300.729 約32%向上 256 3,029.923 2,077.994 約31%向上 512 2,115.624 1,416.822 約33%向上 CPU世代が同じにもかかわらず3割前後の差がついており、今回のLS-DYNAベンチマークでは、 CPU性能だけでなく、hpc8aの大きなメモリ容量や300GbpsのEFAネットワーク帯域といったHPC向けの構成も性能に寄与している ことがうかがえる結果となりました。 3.2 コスト コスト比較 実行時間だけでなく、 全ての並列数でhpc8a.96xlargeが最も低いジョブコスト となりました。 前世代hpcインスタンスとのコスト比較 hpc7a.96xlargeとの比較では、以下のコスト削減効果が確認できました。 並列数 hpc7a コスト コスト改善率 64 $17.15 $10.44 | 約39%低下 128 $11.00 $7.26 | 約34%低下 256 $14.25 $9.14 | 約36%低下 512 $14.45 $9.35 | 約35%低下 前世代のhpc7aから、 4割弱のコスト改善 が見られました。 コンピューティング最適化インスタンスとのコスト比較 c8a.48xlargeとの比較では、さらに差が大きくなります。 並列数 c8a コスト コスト改善率 64 $19.13 $10.44 | 約45%低下 128 $13.98 $7.26 | 約48%低下 256 $17.42 $9.14 | 約48%低下 512 $18.25 $9.35 | 約49%低下 今回のLS-DYNAモデルでは、同じTurin世代でも HPC最適化されたhpc8aを選択することで、c8a比でほぼ半分近くまでジョブコストを抑えられる 結果となりました。 3.3 コストパフォーマンス コストパフォーマンス比較 c7a.48xlargeを「1.0」としたコストパフォーマンス比較でも、 hpc8a.96xlargeが全並列数で最も良い結果 となりました。 また、同じHPCインスタンスであるhpc7aと比較しても、Turin世代のhpc8aは一段低いスコアとなっており、 計算速度だけでなく、ジョブ単位の経済性という面でも世代更新のメリットが大きい ことが確認できました。 以上がLS-DYNAのベンチマーク結果です。 今回のLS-DYNAでは、実行時間・コスト・コストパフォーマンスの全てでhpc8aが優れており、特に前世代hpc7aからの性能向上が4割前後、c8aとのコスト差が5割近くまで広がった点が印象的でした。 4. Siemens STAR-CCM+ ベンチマーク結果 続いてSiemens STAR-CCM+のベンチマーク結果です。 STAR-CCM+では、 128並列・256並列・512並列・1024並列・2048並列 でベンチマークを実施しました。リソースの都合上、一部並列数についてはベンチマークが実施できていないことご了承ください。 4.1 実行時間 ソルバー実行の経過時間比較 STAR-CCM+では、 Turinを搭載したc8a・hpc8aが全体として良好な性能 を示しました。 一方で、256並列まではIntel Xeon 6 Granite Rapids-APを搭載する r8i.96xlarge も良い性能を示しており、LS-DYNAとは少し違った傾向が見られます。 前世代hpcインスタンスとの比較 hpc7a.96xlargeとhpc8a.96xlargeを比較すると、全ての並列数でhpc8aが高速となりました。 並列数 hpc7a 実行時間 [s] hpc8a 実行時間 [s] 性能向上率 128 4,031 2,917 約28%向上 256 2,078 1,732 約17%向上 512 1,079 790 約27%向上 1024 614 467 約24%向上 2048 412 308 約25%向上 256並列では約17%にとどまるものの、全体としては 2割前後から3割弱の性能改善 が確認できました。 コンピューティング最適化インスタンスとの比較 同じTurinを搭載するc8a.48xlargeとの比較では、以下の結果となっています。 並列数 c8a 実行時間 [s] hpc8a 実行時間 [s] 比較 128 3,268 2,917 hpc8aが約11%高速 256 1,702 1,732 hpc8aが約2%低速 512 889 790 hpc8aが約11%高速 ※1024並列・2048並列ではc8aの結果がないため比較対象外です。 LS-DYNAではc8aに対して3割前後の性能差が出ていましたが、STAR-CCM+ではその差は比較的小さく、 ソルバーによってインスタンス特性の効き方が異なる ことが分かります。 4.2 コスト コスト比較 STAR-CCM+でも、 全ての並列数でhpc8a.96xlargeが最も低いジョブコスト となりました。 性能差が比較的小さかった256並列でも、hpc8aはインスタンス単価が抑えられているため、コスト面では優位な結果となっています。 前世代hpcインスタンスとのコスト比較 hpc7a.96xlargeとの比較では、以下のコスト改善となりました。 並列数 hpc7a コスト コスト改善率 128 $8.06 $6.42 | 約20%低下 256 $8.31 $7.62 | 約8%低下 512 $8.63 $6.95 | 約19%低下 1024 $9.82 $8.22 | 約16%低下 2048 $13.18 $10.84 | 約18%低下 全体として、 2割程度のコスト改善 が確認できました。 コンピューティング最適化インスタンスとのコスト比較 c8a.48xlargeとの比較では、128～512並列で以下の結果となりました。 並列数 c8a コスト コスト改善率 128 $9.40 $6.42 | 約30%低下 256 $9.79 $7.62 | 約22%低下 512 $10.22 $6.95 | 約32%低下 実行時間ではc8aとの差が小さいケースもありましたが、コストまで含めると hpc8aは3割前後の改善 となりました。 4.3 コストパフォーマンス コストパフォーマンス比較 c7a.48xlargeを「1.0」として比較すると、STAR-CCM+でも hpc8a.96xlargeが全並列数で最も良いコストパフォーマンス となりました。 また、並列数を増やすにつれて一部のインスタンスタイプではコストパフォーマンスが悪化する一方、hpc8aは大規模並列でも良好な値を維持していました。 以上がSTAR-CCM+のベンチマーク結果です。 LS-DYNAほどhpc8aとc8aの実行時間差は大きくありませんでしたが、 前世代hpc7aに対する性能向上と、hpc8aのインスタンス価格のバランスにより、コスト・コストパフォーマンスではhpc8aが安定して良い結果 となりました。 5. おわりに 全2回にわたり、AWSのhpc8aインスタンスについて、Ansys Fluent、Ansys LS-DYNA、Siemens STAR-CCM+、Cradle MSC scFLOWの4つのCAEソルバーを用いたベンチマーク結果をご紹介しました。いかがでしたか。 今回のLS-DYNAとSTAR-CCM+でも、第1回のFluent・scFLOWと同様に、 hpc8aは実行時間だけでなく、コスト・コストパフォーマンスの観点でも良い結果 を示しました。 特に印象的だったのは、ソルバーによって差の出方が異なることです。 LS-DYNA では、前世代hpc7aに対して4割前後の性能向上が見られ、同世代Turinのc8aに対しても3割前後高速という大きな差が出ました。 STAR-CCM+ では、c8aとの実行時間差は比較的小さい一方で、前世代hpc7aからは2割前後の性能改善が見られ、コストを含めるとhpc8aの優位性が明確になりました。 hpc8aは東京リージョンでも利用できるHPC向けインスタンス ですので、日本国内で大規模なCAEワークロードを実行されている方にとって、ぜひ選択肢の一つとしてご検討いただければと思います！ CAE/HPCでは「とにかく一番速いインスタンスを選べばよい」というわけではなく、ソルバーの特性、並列数、ジョブ単価まで含めた評価が重要です。 今回の結果では単純な速度比較だけでなく、 コストパフォーマンスという指標 も含めてインスタンスを比較しました。 電通総研では、多角的にお客様のワークロードに適したクラウドHPCの構成を検討いたします。 クラウドHPCにご興味をお持ちの方は是非お気軽にお問い合わせください。 末筆になりましたが、本ベンチマーク実施にあたり、ライセンス・ベンチマークモデルのご提供をはじめ、ご協力いただきました各社様、ご関係者の皆様に厚くお礼申し上げます。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @takeda.takafumi レビュー： @yahagi.ginpei1128 （ Shodo で執筆されました ）

こんにちは。エンタープライズ第一本部 戦略ソリューション 1 部の英です。 普段はAWSでWebアプリ作るなどしています。 趣味ではボードゲームを嗜んでおり、なんと自宅に約200種類以上のボドゲを所有しています。ボードゲーマーです。 そんな私のために登場したと言っても過言ではない、とんでもないニュースが飛び込んできました。 → AmazonのAWSサービスを学べるカードゲーム「AWS BuilderCards」日本語版が予約受付中 そう、 AWSのボドゲ です。 ちょっと何を言ってるかわからないので、とりあえず購入してみました。( Amazon購入リンク ) はたして テックブログなのかどうか悩ましいところですが 、今回はこのゲームをAWSエンジニア兼ボードゲーマーとして ガチレビュー をしていこうと思います。 (きっと社内レビューも通るはず) どんなゲーム？ AWSのリソースを組み合わせてシステムを構築し、スコアを競うカードゲームです。 というのは表向きの説明で、その本性としては デッキ構築 ジャンルの 軽量級ボードゲーム でした。 ビルダーのみなさん、ようこそ！ 今日はあなたがITアーキテクトとして採用された初日です！あなたの仕事は、チームを立ち上げ、モダンで、革新的で、クラウドネイティブなアプリケーションをたくさん作ること(最重要！)です！しかし、まだオンプレミスのインフラが残っています。既存のリソースを賢く使い、新しいサービスを採用し、AWSアーキテクチャを構築し、たくさんのWell-Architectedポイントを取得してください！ AWS BuilderCardsは、AWSサービスについて学びながら、実際のアーキテクチャを構築するためのカードゲームです。 AWSに関連した自身の業務やシステムとの結びつけてプレイするのが最適です。 ※引用：パッケージ背面 ゲーム概要 ジャンル：デッキ構築 プレイ人数：2～4人 ゲーム時間：20～30分 対象年齢：12+ 開封の儀 中身はこんな感じ。 コンポーネントはカードのみで、クイックリファレンスカードも内包されています。 正直なところ、私はクイックリファレンスカードだけでルールを理解することは難しかったので、箱の裏面に記載のQRコードからマニュアルを確認させていただきました。 内容物 クイックリファレンスカード(簡易ルール説明)：2枚 Starter Cards(初期デッキ)：10枚×4 AWS Well-Architectedカード(勝利点)：12枚 ビルダーカード(コスト無)：77枚 ビルダーカード(コスト有)：14枚 ゲームの流れ 基本的には以下の2ステップを行います。 手札のカードを使ってアーキテクチャを構築する 得られたクレジットで 新しいカード または 得点カード を購入する 感覚としては クランク！ や ドミニオン に近いゲーム性を感じました。 カードごとに相性があり、コンボを決めて気持ち良くなるタイプのゲームです。 一例として、 「AWS CloudTrail」と「Amazon OpenSearch Service」を組み合わせると1ドローできる 「Amazon DynamoDB」と「AWS Lambda」を組み合わせると1ドローできる のようなかたちで、 実際のAWSでも相性のよいサービス間にシナジーがあるように設計されています 。 ※ドロー：山札からカードを引く 1はログ検索の基盤として、2はサーバレスアーキテクチャの基盤としてよく組み合わせるサービスですよね。 セットアップ 今回は一人まわしを1時間ほどプレイしてみました。めちゃくちゃ自宅の風景ですみません。 以下はセットアップ風景です。 左上の山：コスト無のビルダーカード 右上の山：コスト有のビルダーカード 右上の表の山：Well-Architectedカード(勝利点) 下部のカード：現在取得できるビルダーカード(カードショップのようなもの) プレイ Amazon S3とAmazon CloudFrontを取得しました。 カードテキストを見るとわかるとおり、これらのカードにはシナジーがあります。 左上のビルダーカードから新しいカードを公開します。 AWS Lambdaが公開されました。今所有しているAmazon S3とシナジーがあるので欲しいところです。 ※今回は一人回しですが、複数プレイヤーの場合は欲しいカードが競合します 初手で5枚引きます。全てスタートデッキ(Sが付いているカード)のため、コスト有のカードは買えません。 次のターンになりました。Amazon CloudFrontの効果で1ドローできます。 さらにターンを進めていきます。ここで初めてデッキ圧縮が発動しました。 発動条件はターン開始時の5枚の手札で、Builder Cardの枚数がStarter Cardの枚数より多いことです。（添付の場合、Starter 2枚 < Builder 3枚） オンプレのDocument Storeをゲームから除外します。これでデッキ内のビルダーカードの比率が向上し、デッキサイクルが改善されます。 上の図では2+2+2で6クレジットありますので、AWS Well-Architectedカードも購入できます。 Well-Architected Cardの購入コストは、3点カードが8クレジット、1点カードが3クレジットです。（ここが若干ややこしい） 要素として「おしい！」と感じたところ 以下はボードゲーマーとしての個人の感想です。 序盤が単調すぎる＆序盤の運が後半に響く 初期デッキ10枚ではアーキテクチャ構築によるクレジットをほぼ生み出せないため、序盤はコストなしBuilder Cardを取得するターンが続きやすい 初回のデッキ圧縮が発生したタイミングから急加速する (Builder Cardの比率が上がると、急にデッキが回り始める) コンボが動き始めるタイミングに運要素(カードの引き)が強く、序盤に開いた差が埋まりにくい。 改善案：デッキ圧縮に条件を定めず、毎ターン1枚のカードを除外できるようにする ※このゲームではデッキ圧縮や除外のことをリタイアと呼びます 良い設計をした人が必ず勝てるわけではない 勝利点の計算はWell-Architectedカードの合計です。 カード購入でビルダーカードを選ぶか、Well-Architectedカードを選べるわけですが、ビルダーカードばっかり買っていると良い構築にはなるが勝利点にならない仕組みです。 つまり、 良い構築を直接評価する仕組みではない というわけです。ただ、良い構築ならば、Well-Architectedカードを買うチャンスが多く発生します。 ドミニオン というゲームと同じで、いつ勝負を仕掛けるか(点数を取りに行くか)が勝敗に大きく影響します。 改善案：サブミッションなど追加で勝利点が得られる仕組みを導入する ボードゲームによくある形式として、プレイするたびにランダムな目標がセットされるケースがあります。最近だと デワン というゲームがその仕組みでした。 今回のAWSのゲームであれば、「クライアントはオンプレ環境に大量の書類データを管理しており、耐障害性で困っているようです。ゲーム終了時にEFSやS3を含んだ構築になっていたら追加で勝利点+3点」など各ゲームごとに変化をもたらすシナリオカードがあれば、リプレイ性が向上します。 で、実はなんとAWS公式からこれに近い Mission Card というオプション要素が用意されています。すばらしい！ Mission Cardはベースゲームにも適用でき、Generative AI Add-On Packという追加パックにも含まれています。 引用： 上級ルール英語版 上記は「Boost Developer Productivity（開発者の生産性を高める）」というミッションです。Amazon CodeCatalyst、Amazon Q Developer、Compute Service を組み合わせた指定のアーキテクチャを完成させることで、Mission Cardを得点として獲得できます。 ランダム性が薄く、単調に感じる ボードゲームは良くも悪くも 思うようにいかないところに楽しさ があります。プレイヤーが燃えるポイントです。 現在の仕組みだと、欲しいカードを取り合うプレイヤー間のインタラクションは発生しますが、比較的戦略通りに進めやすいため、ランダム性はやや薄く感じました。 改善案：障害や攻撃要素があるとよいかも 例えば、10ラウンドごとに「災害」「ハッカーによる攻撃」の要素でシステムの一部がダウン(カード除外)するなどのランダムイベントを設定し、その所定ターンまでに対策を打っておかないと、せっかく自分が構築したシステムに被害が出てしまうみたいなのがあると、勝利点を集める以外の 追加目標 になりますし、AWSとしてのリアリティも感じられて、ゲームとしての没入感がより一層高まるのではないかと思います。 と思ったら、なんとこれも拡張版として提供されています。すばらしすぎる。 Resilience Expansion という拡張が存在し、各ラウンド後に Chaos Event が発生。 それをチームで対処しながら耐障害性の高いアーキテクチャを構築していく協力型ゲームになります。さすがAWS。本当に抜け目がないですねえ。 まとめ(感想) はい。というわけで、今回は日本語版のAWS BuilderCardsで遊んでみました。 基本セットだけで遊ぶとやや単調に感じる部分もありましたが、AWSサービス同士の関係性をカードゲームとして直感的に体験できる点は、とても面白かったです。 さらに、Mission CardやResilience Expansionなどの追加要素まで含めると、「AWSを学ぶゲーム」としてかなりよく考えられていると感じました。 あと、単純にカードにAWSリソースが描かれているだけでもテンション上がりますよね。 コレクション目的で購入するのも全然ありだと思います。 1回20～30分で遊べるので、AWSに初めて触れる人向けの勉強会や、採用・研修時のアイスブレイクにも使いやすそうです。 参考 AWS BuilderCards 公式サイト AWS BuilderCards 2nd Edition 公式ルール AWS BuilderCards Builder's Guideline AWS BuilderCards Resilience Expansion AWS BuilderCards Second Edition / Generative AI Add-On Pack 紹介 採用情報 先日Xで「JTCでは社内のAI利用が進んでおらず働きにくい」みたいなのが話題になってましたが、弊社はこの数年間で各種AIツールのライセンスや申請周りがかなり整備され、めちゃくちゃ働きやすいです。 AIを使って効率的に仕事したいSIの方はぜひご検討ください。ClaudeCodeもCodexも使いたい放題です。(2026年9月現在) ↓ のスターを押していただけると嬉しいです。励みになります。 最後まで読んでいただき、ありがとうございました。 エンタープライズ第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 新卒採用-エンタープライズ第一本部 執筆： 英 良治 (@hanabusa.ryoji) レビュー： @azeta.takuya （ Shodo で執筆されました ）

こんにちは。エンタープライズ第一本部 戦略ソリューション 1 部の英です。 普段はWebアプリやスマホアプリの案件などを担当しています。あと、趣味でAIを勉強しています。 世界中がJevの話題で持ち切りなので、流行りに乗ります。 忙しい人向けに短く簡潔に書きます！きっと5分後には Jevわかったかも！ の状態になると思います。 試しに電通総研テックブログの記事100本を高速に仕分け、街に見立てて可視化してみたので、その様子をご覧ください！ 弊社のこれまでの歩み、成長が高速に可視化されます。 Jevとは？ 文章を生成するAIではなく、 小さな判断を高速に返すAI です。 「どのカテゴリか」「何点か」「Yes / No か」を確率付きの構造化データで返します。分類、スコアリング、タグ付け、大量データの仕分けが主戦場です。 どういう仕組み？ 文章(state)と質問(questions)を渡します。質問は3種類で、1回の呼び出しに複数まとめて同時に評価できます。 種類 返るもの 例 Choice 選択肢ごとの確率 この記事の主題は? Score 段階ごとの確率と期待値 技術的な深さは0〜4のどこ? Noul Yesの確率(0〜1) AWSの記事? TypeSafeは 公式ブログ で、新しいモデルアーキテクチャ、Parallel Sampler、 RLCD(Reinforcement Learning for Calibrated Decisions)という学習法を採用していると説明しています。 もう少しだけ中身の話(解釈込み) TypeSafeによると、Jevは従来のLLMとは異なる新しいモデルアーキテクチャを採用し、Parallel Sampler と RLCD（Reinforcement Learning for Calibrated Decisions）という仕組みを使っています。内部アーキテクチャの詳細は現時点では公開されていません。 Parallel Sampler ：LLMのようにトークンを1つずつ生成するのではなく、複数の質問に対する出力を並列に返す RLCD ：判断結果に加えて、その確率や信頼度が適切になるよう学習する 型付きの出力 ：文章ではなく、Choice / Score / Noulなど事前に定義された形で結果を返す 誰が作った？ Diogo Almeida氏らが創業したTypeSafe AI 。Diogo Almeida氏はTypeSafe AIの共同創業者兼CEOで、元OpenAI・Google BrainのAI研究者。 なぜ速くて安い？ LLMはトークンを順に生成しますが、Jevは文章生成ではなく、型付きの判断とその確率を返すことに特化しています。複数の質問に対する出力も1回のクエリで並列に返します。公表値は応答70〜500ms、入力$0.042/百万トークン、 出力は無料 。TypeSafeの評価では、System One型のクエリでLLMより40〜200倍高速とのこと。 ということで試してみる 弊社のテックブログ100本をJevで分類し、 3Dの街を生成するミニアプリ を作りました。本ブログの歩みが可視化されます。 記事1本 = 1リクエストで16問をまとめて聞きます。 Choice ×1: 主題(AI / Cloud / Security / DevOps / Data / Software / Manufacturing / Productivity / Other) Score ×3: 技術的深さ、ハンズオン度、新しさ Noul ×12: AI / AIエージェント / AWS / Azure / Google Cloud / コード / アーキテクチャ / 実験 / ベンチマーク / CI/CD / IaC / セキュリティ アプリからの呼び出しは 計100回、並列5本 。1,600判定を100回で済ませ、5本同時に飛ばして1つ返るたびに次を投げます。 順に呼ぶと約65秒の計算ですが、実測13.26秒でした。Jevは1リクエスト全体で64kトークンまで扱えますが、state と最長の質問1つを合わせて32kトークンまでという制限があります。そのため、今回のように1記事約7,000トークンの場合、100記事を1リクエストにまとめることはできません。 技術は Next.js 15 + TypeScript、3D は React Three Fiber(Three.js)+ drei + postprocessing、状態管理は zustand。 Jev は公式 JavaScript SDK( @typesafe-ai/sdk )をサーバー側から呼んでます。 Jevの結果 街での表現 主題(Choice) 地区 技術的深さ / ハンズオン度 / 新しさ(Score) 高さ / 幅 / 発光 AIエージェント、AWS / Azure / GCP(Noul) リング、屋上のビーコン CI/CD、IaC(Noul) 屋上の回転バー、上部の足場格子 コード / アーキテクチャ / 実験 / ベンチ(Noul) パネル / アンテナ / パーティクル / メーター パネルの見方 建物をクリックすると実 API で再判定し、16問の答えを質問タイプ別に表示します。 Primary Topic(Choice) : 9カテゴリの確率のうち1位。 FEATURES(Noul) : 各項目が Yes の確率。複数同時に成立し、合計100%にはなりません。50%以上のみ表示。 SCORES(Score) : 期待値 ÷ 最大値。「75%」は0〜4の期待値3.0 / 4。 Classification NNN ms : 再判定1回のAPI往復時間。 INITIAL → LIVE : 最初の一括分析と再判定の差。 その後、建物が階層に分解されます。1層 = 1判定で、値が大きいほど厚くなります。 実測結果 100本を並列5で投げた結果(2026-09-24、 jev-1.13.0 、社内プロキシ経由)。 INITIAL BUILD Articles 100 Completed 100 Decisions 1600 Wall-clock time 13.26 sec Avg API latency 651 ms Median API latency 568 ms p95 API latency 1280 ms Fastest 278 ms Slowest 1578 ms Input tokens 707,688 「API latency」はJev APIの往復時間で、モデル内部の推論時間ではありません(ネットワーク分を含む)。 本文は先頭6,000文字で打ち切り。約71万トークン、公表単価で 約0.03ドル 。失敗0件(SDK既定の自動リトライを含む)。 入力トークン量と応答時間の相関はほぼなし(相関係数 0.07)。記事の長さより回ごとの揺れが大きい。 主題の分布: AI / GenAI 37、Security 17、Productivity 16、Cloud 11、Software 7、DevOps 4、Data 4、Manufacturing 3、Other 1。 「Amazon Bedrock Managed Knowledge Base が日本語PDFを扱えない件」は、主題 = AI / GenAI(1.00)、AWS 0.99、コード 0.97、実験 0.97、技術的深さ 3.0/4。製品ではなく「何の記事か」で分類され、AWSであることはNoulで別に拾えます。 5回再判定すると、主題は毎回100%で、境界が曖昧なFeatureだけ数ポイント揺れました。 INITIAL LIVE AI / GenAI 100% → 100% (5回とも) AI Agent 89% → 89% Architecture 59% → 61% / 59% / 58% Benchmark 52% → 50% / 53% / 52% Latency 1176ms → 824 / 859 / 893 / 939 / 1257 ms まとめ ということで今回は話題のJevを使ってみました。 分類モデルに似ていますが、現状扱えるデータはテキストが中心。判断を確率で返すところがポイントです。 とにかく速くて安いのが良いですね。今回の100記事の一括分析だけなら約$0.03、再判定や開発中の試行錯誤まで含めても今回の検証全体で$0.1程度しかかかりませんでした。驚異的ですね。 コールセンターなどで導入した場合、例えば閾値を80%に設定し、信頼度が80%以上ならJevを信頼してシステムで処理し、80%未満なら人の判断に回すみたいな使い方が良いと思います。 社内やシステム内のブルシットジョブをJevに置き換えるみたいな動きは今後あるかもしれませんね。 上司をJevに置き換えても、あなたの仕事は回るかもしれません。 大規模システムでも大した処理ではないのに、無駄にコードが複雑だったりするケースってありますよね。 これらはJevで外出すことで処理やコードを単純化できるかもしれません。 参考 TypeSafe AI 公式ドキュメント: https://docs.typesafe.ai/ Introducing System One Models & Jev(公式ブログ 2026-09-15): https://typesafe.ai/blog/introducing-system-one-models-and-jev 電通総研テックブログ: https://tech.dentsusoken.com/ 採用情報 先日Xで「JTCでは社内のAI利用が進んでおらず働きにくい」みたいなのが話題になってましたが、弊社はこの数年間で各種AIツールのライセンスや申請周りがかなり整備され、めちゃくちゃ働きやすいです。 AIを使って効率的に仕事したいSIの方はぜひご検討ください。ClaudeCodeもCodexも使いたい放題です。(2026年9月現在) ↓ のスターを押していただけると嬉しいです。励みになります。 最後まで読んでいただき、ありがとうございました。 エンタープライズ第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。 私たちは一緒に働いてくれる仲間を募集しています！ 中途採用-エンタープライズ第一本部 新卒採用-エンタープライズ第一本部 執筆： 英 良治 (@hanabusa.ryoji) レビュー： @wang.yuxin （ Shodo で執筆されました ）

はじめまして。 エンタープライズ会計ソリューション本部 第2ユニット 製品開発部の段下 幸太郎です。 現在は2年目社員として、会計ソリューションアプリの基盤開発に従事しています。 はじめに 技術ニュースを毎日チェックしたいけれど、複数のサイトを行き来するのが地味に面倒——そんな課題を解決するために、Claude Codeを使って個人用のニュースアプリ「IndiviNEWS」を作りました。 Hacker News、はてなブックマーク人気エントリー、Zenn・PublickeyのRSSフィードをまとめて取得し、シンプルなリストとして表示するWebページです。iPhoneの「Web Widget」アプリのWebsiteウィジェットに埋め込んで、ホーム画面から閲覧できるようにしています。 コードはすべてClaude Codeに書かせ、 運用コストは実質$0 という構成で実現しました。本記事では、その構成と、AI駆動開発を通じて得られた学びをまとめます。 本記事は、隔週で開催している社内勉強会『25卒技術会』での発表内容をもとに執筆されています。同じ勉強会のメンバーである渡邉 真太郎さんも、 こちらの記事 で発表内容をまとめています。ぜひご覧ください！ Part 1. 作ったもの Part 2. アーキテクチャを理解する 2-1. サーバーレス構成にした理由 2-2. キャッシュによるコスト最適化 2-3. 毎朝の自動ダイジェスト Part 3. 使用した技術スタック Part 4. 学びを整理する 4-1. 知らない技術へのキャッチアップの機会になる 4-2. エンジニア初学者にとって良い成功体験になる 4-3. 個人開発の心理的・金銭的ハードルが下がる まとめ Part 1. 作ったもの IndiviNEWSは、 個人用の技術ニュースアグリゲーター です。 Hacker News / はてなブックマーク人気エントリー / Zenn・PublickeyのRSSを1つのリストに集約 省略表示のシンプルなUI（ウィジェットサイズに最適化） 毎朝6:00(JST)に、その日の見出しをまとめたダイジェストを自動でMarkdownファイルとして記録 複数のニュースサイトを毎朝巡回する手間をなくし、ホーム画面を見るだけで技術ニュースをキャッチアップできる状態を目指しました。 Part 2. アーキテクチャを理解する このアプリの特徴は、 常時起動するサーバーを一切持たない 構成にした点です。 2-1. サーバーレス構成にした理由 リクエストが来るたびに、Vercelのサーバーレス関数（ api/index.js ）がHacker News・はてなブックマーク・RSSの3つのソースにその場でアクセスし、結果をHTMLに整形して返します。リクエストが終われば関数も終了するため、常駐プロセスがありません。 個人用の小さなアプリのために自宅サーバーやVPSを立てて管理するのは、規模に見合わないコストです。サーバーレス構成にすることで、PCの電源を切っていてもアプリは動き続け、かつインフラ管理そのものが不要になります。 2-2. キャッシュによるコスト最適化 Cache-Control: s-maxage=1800 の設定により、Vercelのエッジサーバーがレスポンスを30分間キャッシュします。30分以内の再アクセスはキャッシュから即座に返され、外部への取得は発生しません。30分を過ぎた後の最初のアクセスで、初めて最新情報が再取得される仕組みです。 Widgetsmith自体の更新頻度もこれより長いため、実際の関数実行回数はごくわずかで、無料枠に余裕を持って収まります。ここが今回の構成でいちばん工夫した部分で、「常に最新である必要はなく、ある程度の鮮度が保たれていれば十分」という要件を、キャッシュの持続時間という形に落とし込みました。 2-3. 毎朝の自動ダイジェスト ウィジェット表示とは別に、GitHub Actionsが毎朝6:00(JST)に起動し、その日の全ソースの見出しをまとめた digests/YYYY-MM-DD.md を自動でリポジトリにコミットします。LLMは使わない単純な処理のため、こちらも追加コストはかかりません。 Part 3. 使用した技術スタック 項目 使用技術 実行環境 Node.js ホスティング Vercel（無料 Hobby プラン） バックエンド Vercel Serverless Functions（ api/index.js ） データソース Hacker News API、はてなブックマークRSS、Zenn・PublickeyのRSS キャッシュ Vercel Edge Cache（ Cache-Control: s-maxage ） 自動化 GitHub Actions（毎朝のダイジェスト生成） フロントエンド表示先 iOS「Web Widget」アプリ コード生成 Claude Code デプロイフローもシンプルで、GitHubリポジトリとVercelを連携させることで、 main ブランチにpushするだけで自動的に再デプロイされます。コードを変更しない限り再デプロイは不要で、コンテンツの更新はキャッシュ切れ後の次回アクセス時に自動反映されます。 運用コストについても触れておくと、Vercelの無料Hobbyプランは個人・非商用利用が前提です。今回のような「個人のウィジェット用にニュースを表示するだけ」の用途であれば無料枠内で十分ですが、今後アクセス数が大きく増えたり用途が変わる場合は、Proプラン（有料）への切り替えを検討する必要があります。 Part 4. 学びを整理する 今回、コードのほぼすべてをClaude Codeに書かせる「AI駆動開発」でこのアプリを作りました。実際にやってみて感じたことを3つに整理します。 4-1. 知らない技術へのキャッチアップの機会になる Vercelのサーバーレス関数やエッジキャッシュの仕組みなど、自分がゼロから調べるとなると時間がかかる技術要素も、AIに実装させながら「なぜこの設定が必要なのか」を都度質問することで、実践を通じて理解を深めることができました。手を動かしながら学べるので、ドキュメントを読むだけよりも定着しやすい実感があります。 4-2. エンジニア初学者にとって良い成功体験になる 「個人で使えるアプリを、実際に動く形まで完成させる」という体験は、初学者にとって大きなモチベーションになります。AIがコードの土台を作ってくれることで、「何もわからず詰まって諦める」というハードルが下がり、完成まで到達しやすくなります。完成した後にコードを読み返すことで、設計の意図や技術選定の理由を後から学び直すこともできました。 4-3. 個人開発の心理的・金銭的ハードルが下がる サーバー管理不要・コスト$0という構成をAIと一緒に設計できたことで、「試しに作ってみる」ことへのハードルが大きく下がりました。今後も、ちょっとしたアイデアを気軽に形にする手段として活用していきたいと考えています。 まとめ 今回作ったIndiviNEWSは、あくまで個人用の小さなツールですが、「AIと一緒に技術選定から実装、デプロイまで一通り経験する」という点で得るものが多いプロジェクトでした。 完全にAIにコードを書かせるAI駆動開発は、単なる時短の手段ではなく、 知らない技術へのキャッチアップの機会 であり、 エンジニア初学者にとっての成功体験 を作る手段でもあると感じています。同じように技術ニュースのキャッチアップに悩んでいる方や、AI駆動開発を試してみたい方の参考になれば幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @danshita.kotaro レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

はじめまして。 金融IT本部 プロダクトソリューションユニット 融資ソリューション2部の 渡邉 真太郎 です。 現在は 2 年目社員として、地域金融機関向けの CRM / SFA サービス開発に従事しています。 2025 年 11 月、Anthropic がエンジニアリングブログの記事（ Effective harnesses for long-running agents ）のタイトルに「ハーネス（harness）」という言葉を掲げました。長時間動き続ける AI エージェントを、いかに破綻させずに走らせ続けるか——その「型枠」や「足回り」にあたる仕組みを指す言葉です。 公開直後から、この言葉は一気に界隈を駆け巡りました。「これからはプロンプトエンジニアリングではなくハーネスエンジニアリングだ」といった論調があちこちで見られ、SNS や技術記事のタイムラインは、しばらく「ハーネス」一色だったように思います。 それから半年経ち、当初のバズワード的な過熱はいくらか落ち着きましたが、「ハーネス」は一過性の流行語として消えるどころか「ハーネスエンジニアリング」という一つの設計分野として、むしろ業界に定着しつつあります。 だからこそ今、流行り言葉としてただ持ち上げるのではなく、「 結局ハーネスとは何なのか 」を地に足をつけて理解したいと考えています。 そこで本記事では、ちょっとした検証も交えながらハーネスという概念を改めて整理してみたいと思います。 本記事は、隔週で開催している社内勉強会『25卒技術会』での発表内容をもとに執筆されています。 前回の記事 はクロスイノベーション本部の大岡叡さんが書いています！ぜひご覧ください！ Part 1. ハーネスの概要を知る 1-1. ハーネスの文脈 1-2. ハーネスの定義 Part 2. より詳しく理解する 2-1. ハーネスを体系的に理解する難しさ 2-2. ハーネスの体系的分類 メインとして扱う分類：Meng らの6成分（ETCSLV） 2-3. ここまでのまとめ Part 3. 自分で検証する 3-1. 検証方法 E（実行ループ）: 一時的な失敗からの復帰 T（ツール）: 反復作業を助ける Skill C（文脈管理）: どれが正しい資料かを教える S（状態）: セッションを跨ぐ引き継ぎ L（フック）: 完了前の関門 V（評価）: 別のエージェントによる点検 3-2. 各成分のタスクとハーネス（一覧） 3-3. 確認指標と実験条件 3-4. 結果 Part 4. 学びを整理する 4-1. ベストプラクティスは「そのまま従う」ものではない 4-2. モデルが進化しても効くのは「知識を補う」ハーネス 4-3. Haiku ですら、もう十分に賢い まとめ：ハーネスは「盛る」より「効かせる」 これからのハーネス Part 1. ハーネスの概要を知る 本 Part では、そもそも「ハーネスという言葉すら聞いたことない」という方向けに、 ハーネスの文脈（なぜ生まれたか？） ハーネスの定義（どういう意味の言葉か？） を説明します。 1-1. ハーネスの文脈 AI に仕事をさせるとき、私たちが作り込む対象はここ数年で少しずつ移り変わってきました。 モデルへの指示そのもの から、 モデルに渡す情報 、さらには モデルを取り囲む仕組み へと、工夫する領域が広がってきたイメージです。 プロンプトエンジニアリング ：モデルへの「言い方」を工夫する コンテキストエンジニアリング ：モデルに「何を見せるか（文脈）」を設計する ハーネスエンジニアリング ：モデルの 周り に、計画・記憶・検証・復旧などの 機構 を組む はじめは一問一答が中心で、いかに上手く指示するか（＝プロンプト）が工夫のしどころでした。やがて扱うタスクが大きくなり、検索結果や長い資料をモデルに渡すようになると、限られた文脈に何をどう載せるか、いわゆる「コンテキスト」が問われるようになっていきました。 そして AI エージェントという自律的処理機構の台頭により、上記の工夫だけでは足りなくなった結果生まれたのが「ハーネス（エンジニアリング）」という言葉です。 ちなみに「ハーネス（harness）」はもともと 馬具 を指す言葉で、馬（＝モデル）を制御して仕事をさせる装具、という比喩です。 1-2. ハーネスの定義 次に、ハーネスの厳密な定義に目を向けていきます。 …が、多くの IT 系ホットワードの例に漏れず、「ハーネス」という語もコミュニティで盛んに利用される割に、業界統一での定義はされていません。 よってここでは、多くの一次情報で登場する言葉の使われ方を 2 点程ご紹介します。 エージェント = モデル + ハーネス モデルとは、"Claude Opus" や "GPT" などの「AI 本体」の部分です。 ハーネスはこの周りでモデルを動かし続ける仕組みであり、モデルとハーネスを組み合わせることによってエージェントが成り立っている、と多くの文献では定義されます。 乱暴に簡易化すると、「AI エージェントのうち、 モデル以外のすべて がハーネスである」ということです。 狭義のハーネス 前述の「モデル以外の仕組み」をもう少し分解すると、下記の二つに分けられます。 AI エージェントを走らせる 前 に組んでおく設定: system prompt、ツールの説明、文脈の渡し方など AI エージェントが走っている 最中 に効く機構: ツール呼び出しの処理、文脈の圧縮、安全制約の強制、状態の永続化など このうち前者を scaffold（足場） 、そして後者を狭義としての harness（ハーネス） と呼び分けることがあります。 特に前者がより浸透しているハーネスという語の使われ方だと個人的には感じています。 よって本記事でも、「モデルと共にエージェントを構成する要素（モデル以外のすべて）」という 広義のハーネス を指して、以降「ハーネス」と呼んでいきます。 Part 2. より詳しく理解する 次に、「ハーネスとは何か」をより具体的に整理します。 ハーネスという語はその話題性に反し、概念を深く理解する上でいくつかの障壁が存在します。 ここではまず、その前提となる難しさを整理してから、ハーネスの体系的な理解を試みます。 2-1. ハーネスを体系的に理解する難しさ ハーネスを腰を据えて理解しようとすると、最初に2つの壁にぶつかります。 (1) デファクトの分類が無い ハーネスは非常に広い概念なので、全体像をつかむには「どんな要素からなるののか」という体系・分類が肝要です。 ところが、Anthropic や OpenAI といった各社は、AI エージェントの設計・運用に関する個別のベストプラクティスを数多く公開しているものの（例：Anthropic: Harness design for long-running application development 、OpenAI: Harness engineering など）、「ハーネスとはこう分類される」と断定的には整理しておりません。 結果として、多くの有志が「AI モデル以外のチューニング要素＝ハーネス」という大枠のもとに独自の体系を作っており、 複数のサイトを覗くと、どれも少しずつ違う分類になっている というのが現状です。 (2) 概念が流動的 ハーネスは「モデルを補助する機構」という性質上、モデルが賢くなるほどベストプラクティスが移り変わります。 Anthropic 自身、 記事 の中で 「 ハーネスの各部品は、モデルが自力でできないことについての"仮定"を符号化している。その仮定は誤っているかもしれず、モデルの改善とともに急速に陳腐化しうるので、検証する価値がある 」　　 と述べています。 実際、同社はあるモデル世代で必須だった「コンテキストのリセット機構」を、次世代では丸ごと外せたと報告しています。 つまり 固定的な分類を作りにくく、個々のベストプラクティスを継続的に追いかける必要がある 、というわけです。 この2つを踏まえ、それでも全体像をつかむために、本記事では「 現時点の代表的な分類を1つ選び、それを軸に他の分類を読み解く 」という進め方をとります。 2-2. ハーネスの体系的分類 メインとして扱う分類：Meng らの6成分（ETCSLV） 本記事では、ハーネスを正面から形式的に分解した最新のサーベイ（ Meng et al. "Agent Harness for LLM Agents: A Survey" ）が提案する 6つの成分 をメインの分類方法として利用します。ハーネスを H =（E, T, C, S, L, V） の6成分に分けるもので、それぞれの役割は次のとおりです。 記号 成分 役割（何をするか） 具体例 E 実行ループ 次の手を決め→実行→観測を繰り返し、いつ止めるかを司る 「考える→操作する→結果を見る」を回す ReAct 型ループ。Claude Code が編集とテスト実行を延々と回す動き T ツール モデルが外界にできること（行動の選択肢） ファイル読み書き・シェル・テスト実行、MCP 接続、Skills C 文脈管理 何を見せ、作業中の文脈をどう保つか 関連資料を全部渡す（dump）か必要時だけとる（JIT）か、長くなったら要約する S 状態 会話の外に何を残し、セッションを跨いで引き継ぐか 進捗ファイル、 state.json 、Git 履歴、次セッションへのハンドオフ L フック 節目で決まった処理を強制的に発火させる 「完了の前に必ずテスト/型チェックを通す」ゲート、起動時の init.sh V 評価 成果物が要件を満たすか・終えてよいかを判断する 別エージェントによる要件照合と差し戻し、テストでの合否判定 この分類に当てはめると、例えばプロンプトの調整は C（文脈管理） 、会話内容のログ化は S（状態） 、一時期話題になった "evaluator エージェントの起用" は V（評価） として分類されるハーネスです。 これは 要素の切り分けが最も明示的 で初学者でも考えやすく、またそこそこ 網羅的である 点が非常に優秀です。 よって本記事ではこの分類を基準として扱い、ほかの分類を読み解いていきます。 ※ ただしこれは、 業界で確立した標準ではなく、あくまで最近の代表的な分類の一つ である点には注意してください。また場合によっては上記の分類で適切に分離できないものもあります。 6成分以外にも、代表的な分類がいくつかあります（Wang らの4モジュール、実装解析の "Inside the Scaffold" 12次元、Anthropic / OpenAI の実装パターン、コミュニティの整理など）。 それぞれの詳しい説明に努めたいところですが、本記事では文量の関係で上記の 6成分を基準 にして検証へ進みます。 参考：6成分以外の分類例と、6成分との対応（クリックで展開） (1) Wang らの4モジュール（エージェント構築の統一フレームワーク） A Survey on LLM based Autonomous Agents （Wang et al.）は、エージェントを profiling／memory／planning／action の4モジュールで整理する統一フレームワーク（unified framework）です。ハーネスに特化した分類ではなくエージェント全般が対象で、6成分より粒度は粗めです。 (2) Inside the Scaffold の12次元（実装の実態） Inside the Scaffold （Benjamin Rombaut、※査読前）は、実在する13個のコーディングエージェント（OpenHands・SWE-agent・Aider・Cline・Codex CLI など）のソースコードを解析し、設計を 制御アーキテクチャ／ツール・環境のI/F／リソース管理 の3層・12次元で比較します。「ツールが使える」「記憶がある」といった能力レベルの抽象分類では見えない 実装の差 が、コスト・信頼性・失敗の出方に直結する、と指摘します。 (3) 各社の実装パターン（Anthropic / OpenAI） Anthropic は長時間のアプリ開発で、 initializer＋coding agent の2エージェント（ Effective harnesses for long-running agents 、Justin Young）から、 planner・generator・evaluator の3エージェント（ Harness design for long-running application development 、Prithvi Rajasekaran）へと発展させました。sprint contract（着手前に"完了の定義"を合意）/ context reset / 評価者の分離などが登場し、「 各構成要素はモデルにできないことの"仮定"を符号化しており、ストレステストする価値がある 」という一節は本記事の検証の出発点でもあります。 OpenAI も Codex を題材にハーネスを扱っています。エージェントループを解剖した記事では、Codex の中核を「 core agent loop and execution logic（中核の実行ループと実行ロジック） 」＝ハーネスと定義しています（ Unrolling the Codex agent loop ）。さらに、この設計の営みを「 ハーネスエンジニアリング 」と名づけ、エンジニアの仕事の中心が「コードを書く」ことから「 エージェントが信頼して働ける環境とフィードバックループを設計する 」ことへ移る、と位置づけています（ Harness engineering 、Ryan Lopopolo）。 (4) コミュニティ／実務の整理 有志のまとめや実務家の設定は、E/T/C/S/L/V のような形式分解ではなく、「 解きたい課題ごと 」（メモリ／評価／文脈の渡し方／ガードレール（安全・権限）／観測性／オーケストレーション…）でカテゴリを切る傾向があります。awesome-agent-harness 系のまとめや、実務家のエージェント最適化設定（例：ECC）が代表例。形式分解では埋もれがちな 権限・安全や観測性 を、独立した関心事として前面に出すのが特徴です。 2-3. ここまでのまとめ ここまで「ハーネスとは何か」「どんな要素に分けられるか」について整理してきました。そのうえで強調したいのは、 ハーネスの実装一つ一つは、決して目新しいものではない ということです。 私たちが普段からやっているプロンプトの調整、使うモデルの切り替え、Claude の Skills の利用、 CLAUDE.md でのフォルダ構成や規約の記述などはすべて、すでにハーネス設計の一部です。つまりハーネスに対しての「今までになかった全く新しい概念」という理解は正確ではなく、「 これまで AI モデルの周りで個別にやってきた工夫を、統一的に呼ぶための言葉 」と捉えるのが実態に近いと言えます。 Part 3. 自分で検証する ここまでで、ハーネスの体系をひととおり整理してきました。とはいえ、多くの方が本当に気になるのは「ハーネスを設定すると、AI エージェントの仕事は実際どれだけ良くなるのか」という点だと思います。 そこで本 Part では、Part 2 で選んだ 6成分（ETCSLV）を軸に、実際に手を動かして行った検証の結果を紹介します。 3-1. 検証方法 やったことはシンプルで、「代表的なハーネスを実装し、AI エージェントのタスク処理能力が実際に上がるかを試す」というものです。 6成分それぞれについて、その成分にあたるハーネスと、そのハーネスが効きそうなタスクを1つずつ用意しました。そして同じタスクを「ハーネスなし（素の構成）」と「ハーネスあり」で解かせ、どれだけ差が生まれるかを比べます。実行するモデルは、強いモデル（Claude Opus 4.8）と弱いモデル（Claude Haiku 4.5）の2種類です。成果物の良し悪しは、モデルには見せない隠しテストで機械的に採点しました。 題材は主に、口座開設・入出金・送金といった機能を持つ小規模な銀行コアサービス（TypeScript）で、一部はより小さなユーザー登録 API を使っています。 なお、今回試したハーネスはどれも、Anthropic が公開しているベストプラクティスに基づいています。各成分の説明で根拠として触れるのは、主に次の記事です。 Building Effective AI Agents How we built our multi-agent research system Effective context engineering for AI agents Effective harnesses for long-running agents Harness design for long-running application development 以下、各成分にどんなタスクとハーネスを用意したかを見ていきます。 E（実行ループ）: 一時的な失敗からの復帰 E で解かせるのは、小さなユーザー登録アプリの入力チェックを1つ追加する、という修正タスクです。 仕掛けはテスト実行のタイムアウトにあります。エージェントには修正後に走らせるテストを与えていますが、このテストは最初の1回だけ、強制的にタイムアウト（終了コード124）で失敗し、あたかも処理が異常終了したように見せます。 これに対するハーネスは、一時的な失敗に対するリトライの指示です。「一時的なタイムアウトで失敗しても、コードを作り変えず、まず同じコマンドをもう一度実行する」と伝えます。失敗したらすぐ諦めるのではなく、一時障害なら再試行して続ける、という実行ループの止め方の調整にあたります。 この設計は、障害対処を「モデルの適応力（ツールが失敗していると伝えれば、うまく立ち回る）＋リトライのような決定論的な安全網」で行うこと（multi-agent 記事）、そして実行ループには「制御を保つための停止条件」を設けること（Building Effective Agents）がベースとなっています。 T（ツール）: 反復作業を助ける Skill T で解かせるのは、あるアプリの複数の操作に対して、同じ形の入力チェックを1つずつ実装していく、という反復作業です。似た構造のチェックを、対象を変えながら何度も書いていくイメージです。 これに対するハーネスは、その反復を助ける Skill（Claude の拡張機能）です。チェックの骨格（雛形）を一括で生成する専用の Skill を渡し、繰り返しの手間を肩代わりさせます。ただし正解そのもの（何をどう返すか）は Skill に含めず、骨組みだけを自動化しています。 ツールや Skill でできることを広げて作業を効率化するのは基本の構成要素で、ツール（エージェントが外界にできること）の設計が成果を大きく左右する、という Building Effective Agents の立場に基づきます。 C（文脈管理）: どれが正しい資料かを教える C で解かせるのは、銀行向けの小さなアプリを仕様書どおりに直す、というチェックと修正のタスクです。ただし資料フォルダには、現行の正しい仕様書と、一見それらしい古い仕様書が、中立な名前で並べてあります。どちらが正しいかは中身からは判断できず、放っておくとエージェントは自分の常識に近いほう（標準的に見えるほう）に引きずられ、現行の仕様に反してしまいます。 これに対するハーネスは、どの資料が現行の正本かを示す情報を渡すことです。正解そのものではなく「こちらを信じてよい」という手がかりだけを添えて、エージェントの取り違いを減らします。 限られた注意の予算に、価値の高い情報を過不足なく載せる、という Effective context engineering の考え方に沿っています。 S（状態）: セッションを跨ぐ引き継ぎ S で解かせるのは、ユーザー登録アプリに項目を1つ追加する作業です。このとき、例えば入力の前後の空白をどう扱うか、といった、コードからは導き出せない細かな取り決めを、最初のセッションのプロンプトでだけ伝えます。そして作業を途中で中断し、前のやりとりの記憶を持たない、まっさらな新しいセッションで再開させます。 これに対するハーネスは、作業状態を会話の外のファイルに残しておくことです。取り決めや進捗を外部ファイル（ state.json ）に書き出し、再開時に読み戻すことで、セッションを跨いでも情報が失われないようにします。 各セッションは前の記憶を持たずに始まるため、進捗ファイルや引き継ぎ資料で状態を橋渡しする、という Effective harnesses の中核設計です。 L（フック）: 完了前の関門 L で解かせるのは、あるデータの型に必須の項目を1つ足す、という修正です。この変更を正しく行うと、本体と、テストの無い別の箇所の両方で型の不整合が起きます。ところが公開テストのほうは、型の不整合を無視してパスするよう作ってあります。そのため「テストが通った＝完了」と早合点すると、型崩れを見逃してしまいます。 これに対するハーネスは、完了前の関門（フック）です。作業を「完了」とする前に、必ず型チェックを通し、通らなければ完了させない、という決まった処理を節目で強制します。 完了の前に決まった検査を挟む「ゲート」（Building Effective Agents）と、「エージェントは十分な検証をしないまま完了と宣言しがち」という報告（Effective harnesses）が下敷きです。 V（評価）: 別のエージェントによる点検 V で解かせるのは、互いに影響し合う複数の新しい機能を、まとめて実装する大きめのタスクです。規模が大きく、ある機能の変更が別の機能に波及しやすいため、エージェントは、テストで見つかる取りこぼしを作り込みやすくなります。 これに対するハーネスは、別のエージェントによる評価です。実装を終えた成果物を、まっさらな文脈を持つ別のエージェントがレビュワーという立場で見直し、見つけた問題を直します。自分で自分の成果物を見直す「自己レビュー」と比べ、見る人を分けることの効果を測ります。 作業する側と評価する側を分けることが強力なレバーになる、という Harness design の要点に基づきます。 なお以上の6つに加え、比較の基準線として、情報の偏りが無い素直な完成タスクも用意しました。ここでは「あらゆるハーネスを常時オンにした盛りすぎの構成」が、品質を上げずにコストだけ増やさないかを確認しています。 3-2. 各成分のタスクとハーネス（一覧） 整理すると、各成分に用意したタスクとハーネスは次のとおりです。 成分 解かせたタスク 設定したハーネス E 実行ループ 入力チェックの追加（テストが初回だけタイムアウト） 一時的な失敗へのリトライ指示 T ツール 同じ形のチェックを反復して実装 骨格を一括生成する Skill C 文脈管理 仕様準拠の修正（新旧の仕様書が混在） どれが現行の正本かを示す情報 S 状態 取り決めを渡して中断→新セッションで再開 作業状態の外部ファイル保存と読み戻し L フック 必須項目の追加（型崩れ／公開テストはパス） 完了前に型チェックを通す関門 V 評価 波及の多い大きめの実装 別エージェントによる点検 3-3. 確認指標と実験条件 上記のタスクの検証に利用する指標と実験の条件についても説明します。 今回は、次の3つの指標でハーネスの効き目を見ます。 品質 （不合格数）：モデルには見せない隠しテストのうち、通らなかった数です。少ないほど良い出来で、満点はタスクごとに異なります。 ターン数 ：エージェントが「考える→操作する→結果を見る」を繰り返した数です。多いほど時間がかかります。 コスト ：1回の試行にかかったおおよその費用（米ドル）です。ターン数と並ぶ「無駄の少なさ」の目安で、使うモデルによっても大きく変わります。 また実験の条件ですが、各タスクを 「アーム（ハーネスなし／あり）」×「モデル（Opus・Haiku の2種）」の組み合わせごとに複数回繰り返しました。 反復回数は基本3回ずつ、ばらつきの大きい評価（V）だけ5回です。これらによって計測される結果の平均値をとり、分析を実施します。 各実行は毎回使い捨ての隔離環境で走らせ、前のセッションの記憶（自動メモリ）が混ざらないことを全実行で確認しました。またアーム間で「渡す情報」と「使うモデル」はそろえ、変えるのはハーネスの有無だけとし、採点も固定の隠しテストで統一して、条件をなるべくフェアに保っています。 なお満点はタスクごとに違うので、表は成分同士を直接比べるのではなく、同成分の「ハーネスあり/なし」、「モデルの差」ごとに比較します。 3-4. 結果 検証の結果は下記のようになりました。 成分（満点） モデル 不合格数（ハーネスなし） 不合格数（ハーネスあり） ターン数（なし→あり） コスト（$, なし→あり） 効果 S 状態（6） Haiku 3.0 0.0 18→21 0.08→0.12 あり S 状態（6） Opus 3.0 0.0 17→21 0.38→0.64 あり C 文脈（125） Haiku 12.3 4.7 68→77 0.71→0.71 あり C 文脈（125） Opus 21.0 0.7 37→38 2.73→2.82 あり E リトライ（4） Haiku 0.0 0.0 18→18 0.09→0.10 なし E リトライ（4） Opus 0.0 0.0 17→18 0.37→0.47 なし L フック（2） Haiku 0.0 0.0 18→49 0.11→0.33 なし L フック（2） Opus 0.0 0.0 16→25 0.45→0.83 なし T Skill（84） Haiku 0.0 0.0 68→74 0.65→0.74 なし T Skill（84） Opus 0.0 0.0 53→58 3.13→3.76 なし V 評価（153） Haiku 5.6 2.4 71→132 0.63→1.27 あり V 評価（153） Opus 0.4 0.4 43→91 2.86→5.63 なし 対照（122） Haiku 2.7 2.0 57→91 0.48→0.81 なし 対照（122） Opus 0.0 0.0 21→36 1.92→2.30 なし ※ V の「ハーネスなし」は最初の実装（点検なし）が残した取りこぼし、「ハーネスあり」は別のエージェントが点検・修正した後の数です。ターン数とコストの「あり」は、点検のぶんが上乗せされた合計を表します。また対照の「ハーネスあり」は、あらゆる足場を盛った構成の値を指します。 そのうえで、要点を整理します。 はっきり効果が出たのは、 S（状態）と C（文脈管理）の2つだけ でした。共通するのは、 判断のその瞬間に、必要な手がかりが手元になく、資料の中身からも導けない 、という状況です。S では中断で情報がまるごと消え、C ではどちらの仕様書が正しいか分かりません。 この「情報の欠落」は能力では埋められず、外から手がかりを渡すハーネスだけが効きました 。しかも 強い Opus でも効果は変わらず、C ではむしろ Opus のほうが効果が大きい 。情報が足りないという壁は、モデルが賢くなっても越えられないようです。 反対に、 E（リトライ）・L（完了ゲート）・T（Skill）は、ほとんど差が出ませんでした 。いまのエージェントは、一時的な失敗なら言われずとも自分で走らせ直し、完了前には自分で型チェックを回し、反復の実装も難なくこなします。 手元の情報だけで完結する「閉じたタスク」では、これらのハーネスが肩代わりする仕事はもう残っていない のです。それどころか、足したぶんターン数やコストだけが増える場合もありました。 V（評価）が効いたのは、弱い Haiku のときだけ でした。Haiku は自分の実装に取りこぼしを残しがちで、そこを別エージェントの点検が拾って直します。一方で強い Opus は最初からほぼ満点のため、拾うべき取りこぼしが無く、点検は空振りに終わりました。 そして基準線（対照）でも、 あらゆるハーネスを盛った構成は、品質を上げないまま、コストとターン数だけを増やしました 。 今回の検証でいちばんはっきり見えたのは、 ハーネスは「付ければ効く」ものではなく、モデルが自力では埋められない情報の欠落を補う場合に有効 、ということでした。 Part 4. 学びを整理する 検証を通して見えてきたことを、3つの学びとして整理します。 4-1. ベストプラクティスは「そのまま従う」ものではない 今回、代表的なハーネスをひととおり試してみて、 うまく効いたものは一部だけ でした。しかも効かなかったケースでは、ハーネスを足したぶん コストやターン数だけがかさむ 、という結果すらありました。ベストプラクティスは世の中に数多く公開されていますが、 それを無条件に全部取り入れるのは、むしろ損になりかねません 。まずは最小限の構成でタスクを解かせてみて、 足りないと分かったところだけ、少しずつ足していく 。この順番が、遠回りに見えて確実だと感じました。 4-2. モデルが進化しても効くのは「知識を補う」ハーネス 効いたハーネスに共通していたのは、 モデルが知りようのない情報を、外から渡す ものでした。裏を返せば、 情報の非対称性（モデルの手元にその情報があるかどうか）が、成果を大きく左右する ということです。言い換えると、「モデルの 知能 を肩代わりする工夫」よりも、「モデルの 知識 を補う工夫」のほうが、これからも価値を持ち続けます。モデルが賢くなるほど前者の出番は減っていきますが、後者は賢さでは埋められないからです。 4-3. Haiku ですら、もう十分に賢い 正直に言うと、この検証でいちばん苦労したのは、ハーネスの実装よりも「 差がつくタスクを作ること 」でした。少し難しい課題を用意したくらいでは、 下位モデルの Haiku ですら難なく解いてしまい 、ハーネスの有無で差が出ないという状況が何度も発生しました（そもそも、Haiku という軽量モデルの存在を意識していない方も多いのではないでしょうか）。ちょっとした修正のたびに Sonnet や、まして Opus を呼んでいる人は、 一度 Haiku に任せてみる と、その賢さに驚くかもしれません。 まとめ：ハーネスは「盛る」より「効かせる」 本記事の出発点は、「ハーネスは盛れば効くのか？」という素朴な問いでした。検証を経て出た答えは、はっきり「いいえ」です。 効いたのは、 モデルが自力では埋められない情報の欠落を補うハーネスだけ でした。逆に、モデルの“知能”を肩代わりしようとする足場は、モデルが賢くなるほど出番を失っていきます。ハーネス設計の勘所は、あれもこれもと機構を盛ることではなく、 「このタスクで、モデルの手元に本当に足りていないものは何か」を見極め、そこだけを的確に埋めること にあります。 よく我々は「開発の最初期に完璧なハーネス設計をする」ということにとらわれがちですが、この結果を考えると最初にすべてを整えるのは悪手であり、むしろ最初は最低限、そこから少しずつ修正を加えていく方法がベストであるといえそうです。 これからのハーネス モデルは、これからも賢くなり続けます。その分、いま「ベストプラクティス」と呼ばれている工夫の多くは、来年には不要になっているかもしれません。実際 Anthropic 自身、あるモデル世代では必須だった機構を、次の世代では丸ごと外せたと報告しています。ハーネスとは、常に更新され、ときに“引き算”もされていくものです。 そうなると、ハーネスエンジニアリングの重心は、「モデルの不得手をどう補うか」から、 モデルが知り得ない情報・文脈・権限を、いかに的確に渡すか へと移っていくはずです。Part 2 で紹介したように、OpenAI はエンジニアの仕事の中心が「コードを書くこと」から「エージェントが信頼して働ける環境とフィードバックループを設計すること」へ移りつつある、と述べています。ハーネスを考えることは、これからますます、 AI と一緒に働く環境そのものを設計すること に近づいていくのだと思います。 ハーネスエンジニアリングは、流行り言葉として消えるどころか、モデルが進化するほど奥行きを増していく、息の長いテーマだと思います。まずは素の構成で走らせ、足りない情報だけを足してみる。その小さな一歩から、ぜひ始めてみてください。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @watanabe_shintaro レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

⚠️ 【注意】本記事の内容は2026年8月17日時点のものです。日本語PDFの対応状況はAWSのアップデートにより変わる可能性があるため、最新の状況は公式ドキュメント等をご確認ください。 クロスイノベーション本部の大岡叡です。 Amazon Bedrock Managed Knowledge Base（以下 Managed KB）に電通総研の有価証券報告書(PDF)を入れて、営業利益の推移に関する質問をしてみました。ところが返ってきた営業利益は、全て誤った数値でした。 原因を調査したところ、そもそも検索で参照されているチャンク自体に日本語が入っていないことが分かりました。最終的に AWS サポートへ問い合わせをして、「Managed KB は現時点で日本語 PDF をサポートしていない」という回答をいただきました。本記事では、構築→テスト→原因調査→サポート問い合わせの過程を書きます。 本記事は、隔週で開催している社内勉強会『25卒技術会』での発表内容をもとに執筆されています。 前回の記事 はエンタープライズ第二本部の菊池祥汰さんが書いています。ぜひご覧ください。 Managed KB とは 構築 質問してみる 返ってきた答えがおかしい 原因を探る チャンクから日本語が消えていた PDF が悪いわけではない AWS サポートに確認した ワークアラウンド まとめ Managed KB とは 2026年6月17日に GA した、フルマネージドの RAG 基盤です。従来の Knowledge Bases では OpenSearch Serverless などのベクトルストアを自分で用意する必要がありましたが、Managed KB ではベクトルストアも AWS 側が持ちます。チャンク戦略やパース戦略もあらかじめ決められていて、利用者が選ぶ余地はありません。埋め込みモデルなど一部の設定は変更できますが、いずれも既定値のままで動きます。つまり利用者が実質的に指定するのは、データソースだけです。 本当にデータソース指定だけで構築できるのか、実際に試してみました。検証は東京リージョンで行いました。 構築 題材は電通総研の有価証券報告書にしました。5年分の有価証券報告書をS3 バケットに dentsusoken-ir/ というプレフィックスを切って置きました。 続いて、ナレッジベースのコンソール画面で Create Managed KB というボタンをクリックし、以下の画面で設定を入力します。 入力したのは、ナレッジベース名・データソース名・S3 の URI の3つだけです。従来のKBなら悩むはずのベクトルストア、解析戦略（Managed parser）、チャンキング戦略は設定する必要がありません。埋め込みモデルだけは選択の余地がありますが、こちらも推奨の Managed embeddings model が初めから選ばれています。拍子抜けするほど決めることがありません。 補足：Managed parser は PDF に対応しています。 作成したらデータソースを同期します。 これでRAGの構築が完了です。 質問してみる コンソールにテスト画面があるので、そのまま質問してみます。左が設定、中央が対話、右がトレースとソースチャンクという構成です。 設定はいずれも初期値のままにしました。 API： Agentic retrieval with answer generation 。 モデル： Managed model （Equivalent to Claude Sonnet 4.6 or better） Maximum agentic iterations：5 従来のKBと異なり、Managed KBではエージェンティック検索のAPIを提供しています。 せっかくのエージェンティック検索なので、複数のファイル・表をまたがないと答えられない質問にしました。 2021~2025の従業員一人当たりの営業利益と平均年間給与は連動していますか。各年度の営業利益、従業員数、平均年間給与を挙げて分析してください。 トレースを見ると、質問がきちんと分解されています。 推測検索のあと 従業員数 平均年間給与 提出会社の状況 と 営業利益 2022年度 2023年度 2024年度 2025年度 の2本に分解し、次の反復では 主要な経営指標等の推移 営業利益 従業員数 へ絞り込んでいます。検索の組み立て方としては良さそうで、ここまでは順調に見えました。 返ってきた答えがおかしい 「整合的に抜き出すことができませんでした」と断りつつ、営業利益の表が提示されます。一見それらしい数字が並んでいますが、原本と突き合わせると、こうなっていました。 決算期 回答値 原本の営業利益 回答値の正体 2021年12月期 13,224 13,736 経常利益 2022年12月期 11,914 18,590 営業活動によるキャッシュ・フロー 2023年12月期 18,590 21,028 前期の営業利益 2024年12月期 21,028 21,039 前期の営業利益 全ての年度が誤っています。前半2つは別の勘定科目、後半2つは「前期／当期」2列表の前期側を拾っています。 営業利益は有価証券報告書の連結損益計算書などに記載されています。つまり、RAG側が何らかの原因で数値を取ってこれていない状態です。 原因を探る 営業利益を取ってこれない原因を調査しました。 チャンクから日本語が消えていた 上記のテスト画面で「ソースの詳細」を押すと、実際に取得されたチャンクを確認できます。 H 3#3 - 51 - - ALL C. A A . 4 LICHT. n. 1 4 : =6 17.5% : 17.5% L+3. d. 1 1 (P), #. 12 1 TOTAL (P), ) KEV''. 5 307 ** I 3 1 3 1 ) 1 0 L, (*) 1 35 3 LTD. () 11 , 1 10 K 1 T THESTED. 日本語がひとつも見当たりません。 17.5% や THESTED といった数字・記号・アルファベットだけが含まれています。 PDF が悪いわけではない PDF には、文字がテキストデータとして埋め込まれているものと、紙をスキャンした画像だけのものがあります。後者であれば画像から文字を起こす（OCR）しかなく、日本語の認識精度が落ちることもあると思います。 しかし今回のファイルは前者です。手元で pypdf にかけると、先ほどの表がそのまま抽出できます。 from pypdf import PdfReader print (PdfReader( "FY2021_annual_securities_report.pdf" ).pages[ 21 ].extract_text()) 売上高 108,679 112,085 ＋3,406 103.1％ 営業利益 12,189 13,736 ＋1,547 112.7％ 経常利益 11,502 13,224 ＋1,722 115.0％ チャンクに日本語が存在せず、PDFファイル自体に問題が無いということから、Managed parser が日本語をうまく解析できていない可能性が高いと考えました。 AWS サポートに確認した 以上の事実関係と仮説をまとめて AWS サポートに問い合わせました。以下は 2026年8月時点の回答の要旨です。 Managed KB は現時点で日本語 PDF をサポートしていない。 Managed parser が PDF をどう処理しているかは内部情報のため非公開 同様の要望は他の利用者からも寄せられており、本件も機能改善要望として開発チームにフィードバックされる。 日本語対応していないという回答を受けて、 Retrieve API でチャンクのメタデータを覗いてみたところ、 "_language_code": "en" となっていることが分かりました。 " metadata ": { " _file_type ": " PDF ", " _document_title ": " FY2024_annual_securities_report.pdf ", " _language_code ": " en ", ... } ワークアラウンド KB で日本語 PDF を扱う場合、現時点では従来型の Customer-managed KB を使うのがワークアラウンドになります。 検証として、同じデータソースで Customer-managed KB を作り（解析戦略=Amazon Bedrock デフォルトパーサー）、5 年分の営業利益を聞いてみました。 5 年分すべて原本と一致し、ソースチャンクにも日本語がそのまま残っていることが確認できました。 まとめ Managed KB の使い心地は最高でした。データソースを指定するだけで、ものの数分で RAG が立ち上がります。 ただし、日本語 PDF は現時点で読めません。AWS 側で対応される日を楽しみに待ちます。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @ooka.toru レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

はじめに：設計における2つのアプローチ こんにちは。電通総研の技術統括推進ユニット 江夏秀俊と、同じく電通総研の製造エンジニアリング本部 エンジニアリング1ユニット 齊藤智明です。 製品開発やエレキ・メカ設計の現場で、次のような状況を目にすることはないでしょうか。 「機能ブロック図などの図面（定性モデル）を作成してみたものの、その後の詳細設計への活かし方が分からない」 「外部の提案や手法に沿って構造の整理を進めたが、具体的な仕様決定やトレードオフの判断で行き詰まる」 「設計判断を迫られても数値的な根拠がなく、最終的に経験則や勘に頼って決定してしまう」 多くのエンジニアは、普段から数式や計算（定量モデル）を用いて設計業務を行っていることと存じます。しかし、導入された定性モデルとの付き合い方や、両者の役割分担に悩まれるケースも少なくありません。 本記事で最初にお伝えしたいのは、 「定性モデルは不要」と否定するつもりは一切ない ということです。設計活動には役割の異なる「定性モデル」と「定量モデル」の2つが存在し、 両者を組み合わせることで、より根拠のある設計判断が可能 と考えます。 定性モデル： 構成や機能を分解・整理・共有するためのアプローチ（例：機能ブロック図、概念図、システム構成図） 定量モデル： パラメータや物理量を計算・解明するためのアプローチ（例：数式モデル、1DCAE(Simulink、Modelica言語など)/3DCAE） ※本記事では議論の前提として、ドキュメントベースの静的な図面だけでなく、SysML等のモデリング言語による記述であっても、外部ソルバーや物理計算と自動連携されていない静的な記述に留まるものは便宜上「定性モデル」として扱います。 `【図1：定性モデルと定量モデルの役割と、両者を組み合わせた設計判断のプロセス】` 本記事では、定性モデルが持つ本来の価値を整理したうえで、なぜ定性モデル「だけ」では設計判断が難しいのかという理由と、本来必要な「定量モデル」が担う役割について解説いたします。 定性モデルの重要な役割 ～全体構造の共通言語として～ 前提として、機能ブロック図などの定性モデルは、設計活動において「全体構造の共通言語（マップ）」として機能します。 議論の土台： 既存製品やシステム全体像を俯瞰し、チームや部門間で認識を揃える。 概念の共有： 専門外のメンバー（他部署やステークホルダー等）に対し構造をわかりやすく説明する。 インターフェース整理： 機能同士の繋がりを明確にし、モジュール化や仕様のモレを防ぐ。 市販の汎用ユニットや仕様や許容範囲が明示された規格部品を組み合わせるだけのアセンブリ設計であれば、各モジュールの性能や接続条件が事前に規定されているため、定性モデル（構成図など）だけでも モジュールの選定や組み立て が成立する場合があります。 しかし、 新領域の製品開発や新規設計、極限までの性能追求が求められる開発 においては、構成図だけでは「物理的に本当に成立するか」を担保することが困難です。どれだけ綺麗な機能ブロック図を描いたとしても、それ単体で部品の寸法や仕様の数値が決まるわけではないためです。 定性モデルだけでは「設計判断」が難しい3つの理由 定性モデル「だけ」で設計判断（仕様決定やトレードオフ）を下そうとすると、次の3つの壁に突き当たると考えられます。 理由1：数値による「性能評価」が難しい 機能ブロック図の上に「冷却ファンから熱交換器へ風を送る」と定義することで、機能の定義や接続関係は明確になります。しかし、「具体的に温度が何℃低下するか」という物理量による定量的な評価が難しくなります。 その結果、「良くなりそう」という感覚だけで判断を進めてしまい、後工程の実機テストなどの段階で目標性能に届かないことが発覚し、大幅な手戻りが発生するリスクがあります。 理由2：「設計限界」の評価が難しい 「どこまで板厚を薄くしたら破壊するか」「最大荷重がかかった際に変形が許容内に収まるか」といった限界値（マージン）は、ブロック図を描くだけでは見極められません。 結果として、限界が分からないために安全側を見すぎて過剰設計となり、コスト高や重量増加を招くか、逆に限界を見誤って品質リスクを抱える懸念があります。 理由3：対象の「物理特性」の評価・追跡が難しい SysMLなどのアーキテクチャ図やブロック図の補足として、注釈テキストで V = IR（オームの法則）や F = ma（運動方程式）などといった具体的な数式が併記されているケースがあります。 しかし、モデル図やドキュメントの上にいくら数式が書かれていても、それらは人間が読むための「文字情報（注釈）」に過ぎません。モデル内の変数同士がプログラムや計算式として相互に自動連動（自動計算）されていない以上、仕様変更や異常が発生した際の静的・動的な物理応答を評価・追跡することは難しくなります。 `【図2：定性モデルの壁と定量モデルによる補完】` 定性モデルを補完し、より確かな設計判断を下すための「定量モデル」 定性モデルを補完し、より確かな設計判断を下すためには 物理現象を数学的に表現した「定量モデル（数式・シミュレーション）」 の活用が重要となります。 もちろん、定量モデルの構築にはモデル作成コストや専門知識が必要という側面もあります。だからこそ、まず定性モデル（全体マップ）で「どこを定量計算すべきか」の範囲を絞り込み、その上で「1DCAE（集中定数モデルやModelicaなどを活用したシステムレベルのシミュレーション）」や「3DCAE（構造・流体・電磁界解析など）」といった定量モデルを活用することが効率的です。 定量モデルを活用することで、3つの壁に対応した設計判断が可能になると考えられます。 1. 性能の数値化（理由1へのアプローチ） 「〇〇Wの熱が発生した際、何℃まで温度が上昇するか」といった具体的な数値を物理シミュレーションによって算出し、定量的な評価結果として性能を評価できます。これにより、試作前に性能未達リスクを低減できます。 2. 限界・境界の予測とトレードオフ評価（理由2へのアプローチ） 製品が破壊・作動不良を起こすギリギリの境界値（設計限界）を予測・評価できます。これにより、過剰設計（オーバースペック）を防ぎつつ、「軽量化と強度のトレードオフ評価（最適解の探索）」などの判断をデータに基づいて下すことが可能になります。 3. 物理特性（動作）のトレースと実測検証（理由3へのアプローチ） 変数同士が計算結合されたモデルを用いることで、仕様変化に伴う定常応答や、時間経過に伴う動的な過渡応答を数学的にトレースできます。また、実測データ（ベンチテスト）と比較することで、モデルの妥当性の確認（バリデーション）やトラブル原因の分析に活用できます。 まとめ：定性で共有し、定量で判断する 「機能ブロック図を作成して完結した気になってしまう（その後の使い道が見えない）」という課題に対する有効なアプローチは、両者の役割分担を正しく理解することだと考えます。 定性モデルは「認識合わせのツール」： システム全体の構造や機能を関係者間で共有し、共通言語を作るために使う。 定量モデルは「設計判断のツール」： 物理的な数値根拠を導き出し、仕様決定やトレードオフ評価を行うために使う。 機能ブロック図などの定性モデルの上に、単に結果の数値を注釈としてメモするだけでは、計算可能な形で定量化されたとは言えません。定性モデルで全体像を可視化しつつ、その裏側にあるシミュレーション等の定量モデルと連携させて数値的な根拠に基づく設計判断を下す。この「両輪のアプローチ」を正しく機能させることが、手戻りの低減や、より確かな設計判断へ繋がる一助になるのではないかと考えております。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @koka.hidetoshi レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

こんにちは。エンタープライズ第二本部 プラットフォームエンジニアリング部 2年目の菊池祥汰です。業務では AI サポートセンターとして生成 AI / LLM 活用案件や dJ グループ内の生成 AI 利活用推進などを行っています。 この記事では、従量課金・投資回収フェーズに入っている筈の LLM ベンダーが、昨今ベンチマークスコア比のトークン単価を下げ続けているという事実に対して、検証ベースの定量的な評価を述べます。より具体的に言うのであれば、 「Claude Mythos/Fable 級と評されるモデル（Claude Opus 5）が、より安いトークン単価で提供されているように見えるのに対して、実際の請求金額は本当に下がっているのか？」 という問題について検証を行います。 はじめに 検証 結果 品質評価 推論量 請求額 結論 おわりに はじめに 2026 年に入ってから、ベンチマークスコアに対するトークン単価は下がり続けています。最上位モデルに 0.5% 差まで迫る性能が、その半額で手に入るようになりました。 2026 年 7 月 25 日、Anthropic から Claude Opus 5 が発表されました。その上位（フラグシップモデル）には、Claude Mythos / Claude Fable 5 が存在します。Claude Mythos は、評価環境のネットワーク設定不備から実在の組織インフラに到達し、演習課題の一部と誤認して認証情報を持ち出す操作を行った 事例 が公表されているモデルです。その Mythos に強力な制限ハーネス（メタプロンプト）を設定し公開された Claude Fable 5 は、そのサイバーセキュリティ能力の高さから来る懸念から、2026 年 6 月 12 日に 米政府の輸出規制の対象となりました 。 領域によっては同等かそれ以上のベンチマークスコアを誇る Claude Opus 5 は、CursorBench 3.2 の最大 effort で最上位の Claude Fable 5 の最高スコアに 0.5% 差まで迫りながら、コストは半分だと 公表されて います。 モデル CursorBench 3.2 入力 / 出力（1M トークンあたり） Claude Fable 5 70.5% $10 / $50 Claude Opus 5 70.0% $5 / $25 Claude Opus 4.8 62.3% $5 / $25 Claude Sonnet 5 61.5% $2 / $10（2026 年 8 月 31 日までの導入価格。9 月 1 日以降は $3 / $15） 表の絶対値は第三者による集計です。ベンチマークの運営元である Cursor 自身は、既定の effort で Claude Opus 5 が 66.7%、Claude Fable 5 が 66.5% だと 述べて います。 Claude Opus 5 の $5 / $25 が Claude Opus 4.8 から据え置きであることは 公式発表文 に明記があり、 Claude Sonnet 5 の発表 は Claude Opus 4.8 に近い性能をより低い価格で提供するモデルだとしています。最上位の半額で 0.5% 差、さらにその 5 分の 2 の導入単価で前世代の Opus に近い性能、という並びです。 同じ動きは Anthropic に限りません。OpenAI は 2026 年 7 月 30 日に GPT-5.6 ファミリーの API 価格を改定 しました。7 月 9 日の GA 時点と比べると、上位の Sol は入力 $5 / 出力 $30 で据え置き、中位の Terra は入力 $2.50 / 出力 $15 から $2.00 / $12 へ 20% の引き下げ、下位の Luna は入力 $1.00 / 出力 $6.00 から $0.20 / $1.20 へ 80% の引き下げです（いずれも 1M トークンあたり）。 ベンチマーク 条件 GPT-5.6 Sol のスコア ARC-AGI-3 OpenAI の公式ハーネス 13.3% ARC-AGI-3 推論保持と圧縮を加えたハーネス 38.3%（出力トークンは 6 分の 1） ARC-AGI-3 参考: 人間の平均 48% Terminal-Bench 2.1 標準 88.8%（前世代 GPT-5.5 は 88.0%） Terminal-Bench 2.1 Ultra モード 91.9% ※ただし、GPT-5.6 は「スコアを保ったまま単価だけが下がった」と読むことはできません。推論の保持と圧縮をハーネス側で加えると スコアは約 3 倍になり、出力トークンはむしろ 6 分の 1 に減った と報じられています。 Terminal-Bench 2.1 の数字 は前世代の GPT-5.5 から 0.8 ポイントの改善です。 これらの数字を額面通り受け取るのであれば、各社は 性能を向上させつつ値下げを続けている ということになります。一方で、各 LLM ベンダーは従量課金制を強化し、基盤投資を回収していくフェーズに入っており、これらのスタンスの違いには若干の違和感が残ります。 単価表が約束しているのは「1 トークンの値段」だけであって、「1 つの仕事の値段」ではありません。これは当然のことですが、 「Claude Sonnet 5 の単価は Claude Opus 5 の 5 分の 2 である。したがって、同じ実装作業を投げれば、請求額も 5 分の 2 になる」 とは言い切れないわけです。 この命題が成り立つのは、同じ仕事に必要なトークン数がモデルによらず概ね一定であるときだけです。 もし安いモデルが、上位モデルと同じ品質に到達するために推論を厚く取ることによって、結果的に多くのトークンを消費しているのであれば、単価の安さは請求書に届く前に目減りしている・あるいは逆転している ことになります。すなわち、ここには 「安いモデルで推論を積むことでユーザの心理的抵抗を下げ、スコアを担保しながらの課金につなげている」 という疑いが残されています。 検証 今回は、Claude Opus 5 が発表されたばかりの Anthropic にターゲットを絞り、検証を行います。 やることは可能な限りシンプルなものとし、まったく同じ要件定義書を Claude Sonnet 5 / Claude Opus 5 / Claude Fable 5 に渡し、Claude Code（v2.1.220）で完全自動に実装させます。2 題材 × 3 モデル × 3 試行の計 18 本を回し、実装にかかった料金を計測しました。 題材には、仕様が外部に一意に存在してエッジケースが密集している実装課題を 2 つ選びました。これは、題材が簡単すぎるために 3 モデルとも差が出ないという結果を回避するためです。一方で、それぞれは大規模な開発案件というわけではなく、 弊社の社員が日常的にAIに伴走させているような、中規模かつ要件ドリブンの思考判断作業に近しいタスクドメイン を想定して設計しました。 題材 実装するもの 踏みやすいエッジケース 隠しテスト B: 数式評価エンジン 表計算ソフトの数式評価器。セル参照、演算子の優先順位、循環参照の検出、依存関係にもとづく再計算 単項マイナスがべき乗より強く結合する（ =-2^2 は 4.0 ）。 ROUND は 0 から遠い方へ丸める（Python の組込み round はバンカーズ丸めなので、素直に実装すると落ちる） 119 件 D: 繰り返し予定の展開器 iCalendar（RFC 5545）の RRULE のサブセットを日時列に展開する。月末、第 n 曜日、除外日、タイムゾーン 第 5 月曜がある月、13 日の金曜日といった暦の際どい日付を期待値に置いた（ calendar モジュールで独立に検算） 105 件 条件は以下のとおりです。 推論設定 : --effort high を全条件で固定 個人設定 : --safe-mode で CLAUDE.md・スキル・フック・MCP を一括で無効化 外部情報 : --disallowed-tools WebSearch WebFetch で取得を封じる 指示文 : 全条件で完全に同一の 1 種類だけ 実装量 : 要件定義書でファイルパスと公開 API を固定 採点 : 実装側に見せない隠しテストの通過率。隠しテスト自体は、別に書いた参照実装で全件通ることを先に確認 トークン数は claude -p --output-format stream-json の最終 result イベントに API 報告値がそのまま入るため、これを主軸にしました。課金額は CLI が出す costUSD を鵜呑みにすることなく、 公式の料金ページ の単価とキャッシュの倍率で独立に再計算しました。この検算で、 CLI が Claude Sonnet 5 を標準価格の $3 / $15 で計算していることが判明したため、以降の金額はすべて現行の導入価格で引き直した正確な値となっています。 結果 品質評価 品質面では、18 本のうち 17 本が満点となりました。唯一の失点は、Claude Sonnet 5 が題材 D の 3 本中 2 本で BYDAY=+2TU （序数に明示的な正符号を付けた表記）を不正と判定したもので、全 105 件中 1 件です。RFC 5545 の構文では序数の前に + を置けるので実装側の誤りですが、私の要件定義書が明示的な正符号に触れていなかったのも確かで、これを品質差の根拠として強く扱うのは無理があるでしょう。 筆者の想定通り、この難度の範囲では、3 モデルの品質に差は出ませんでした。 したがって、 同じ成果に到達するまでにいくら払ったのか、という比較 がそのまま成立します。 一方で、所要時間と実装行数にはモデルごとの傾向が見られます。3 試行の平均で、 Claude Opus 5 が両題材で最も速く（516 秒 / 366 秒）、Claude Fable 5 が両題材で最も短いコードで満点を取りました（605 行 / 325 行） 。 推論量 思考トークンには、API に分離したフィールドが存在しません。そこで、CLI が思考中に流すイベントから値を取得しました。 { " type ":" system "," subtype ":" thinking_tokens "," estimated_tokens ": 11050 ," estimated_tokens_delta ": 100 } estimated_tokens は思考のひと続き（エピソード）ごとに 0 から積み上がり、次のエピソードでリセットされます。増分の総和と、エピソードごとのピークの総和を別々に計算して突き合わせ、完全に一致することを確認しました（Claude Opus 5 の 1 本で 17,713）。 題材 モデル 出力トークン（平均） 思考トークン（平均） 思考の比率（3 試行の範囲） B Claude Sonnet 5 63,259 46,619 73.7%（72.4 〜 76.0） B Claude Opus 5 45,339 21,692 47.7%（42.1 〜 52.4） B Claude Fable 5 49,802 33,246 66.8%（65.5 〜 68.3） D Claude Sonnet 5 44,945 30,783 68.5%（68.0 〜 69.0） D Claude Opus 5 32,846 13,448 40.6%（31.8 〜 49.5） D Claude Fable 5 33,411 18,805 56.0%（49.8 〜 60.3） 思考の比率は、両題材で全く同じ順序になりました。 Claude Sonnet 5 が最も厚く、Claude Opus 5 が最も薄く、Claude Fable 5 がその間です。 3 試行の範囲も、Claude Sonnet 5（68 〜 76%）と Claude Opus 5（32 〜 52%）で重なりません。 出力トークンの内訳。最も安いモデルが、最も厚く思考している 厚みの出どころは、往復回数ではありません。Claude Sonnet 5 と Claude Opus 5で平均同士の比を取ると、思考トークンが 2.15 倍（題材 B）と 2.29 倍（題材 D）、出力トークンが 1.40 倍と 1.37 倍で、題材が違ってもほぼ揃っています。一方で API リクエスト数の比は 0.62 倍と 1.13 倍で、題材によって逆転しています。テストに落ちて直す往復が多いのであれば、リクエスト数の比が安定して 1 を超えるはずです。すなわち、 トークン厚みの差は、1 リクエストあたりの思考の厚さから来ている と言えるでしょう。 Sonnet 5 の推論が厚いのは概ね予想どおりでしたが、Opus 5 よりも Fable 5 のほうが厚いのは予想外でした。これであれば、 分野によっては Fable 5 よりも Opus 5 のほうがコストパフォーマンスの良いモデルである と断言してしまって良いと思っています。トークン単価・入出力トークンともに Fable 5 を下回るのであれば、費用削減効果はそのまま二重に効いてくるでしょう。 請求額 公式の現行価格で再計算した、1 本あたりの請求額です。 題材 Sonnet 5 Opus 5 Fable 5 Opus 5 ÷ Sonnet 5 Fable 5 ÷ Opus 5 B $1.035 $2.018 $3.990 1.95 倍（単価比 2.50） 1.98 倍（単価比 2.00） D $0.823 $1.471 $2.889 1.79 倍（単価比 2.50） 1.96 倍（単価比 2.00） 単価は 2.5 分の 1 なのに、請求は 1.79 分の 1 程度に収束しました。 冒頭で置いた命題は否定された一方で、否定のされ方は予想とは異なっていました。筆者は「ともすると、推論の厚みと反復回数の重なりによって、Sonnet 5 の総課金料金のほうが高いのでは？」ところまで疑っていましたが、そうはなっていません。Claude Sonnet 5 は Claude Opus 5 の 1.8 〜 2.0 分の 1 の請求で、同等の品質に到達しています。 安いモデルは、ちゃんと安いのでした。 一方で、仕事あたりの総費用は 単価表から受ける印象ほどの割引率には届いていません。 しかも、目減りは全階層で起きているわけではありません。単価差のうち実際に請求額の差として実現した割合は、Claude Fable 5 ÷ Claude Opus 5 では 98% ですが、Claude Sonnet 5 が絡むと 70 〜 78% まで落ちます。 請求の 55 〜 61% 程度は出力トークン由来で、その出力の 4 割から 7 割が思考です。掛け合わせると、 請求全体のおよそ 3 割から 4 割が「思考」に対する支払い になります。しかも思考の中身は記録に残りません。思考トークンが出力トークンとして課金されることは 公式ドキュメントの Thinking に明記されていますので、適切なモデル選択・適切な effort 設定が重要だという一般論を支持するような結果となりました。 なお、ここまでの Claude Sonnet 5 の金額は、導入時の割引価格（$2 / $10）にもとづいています。9 月 1 日以降の標準価格（$3 / $15）で引き直すと、差は縮みます。 題材 Claude Sonnet 5（標準価格） Claude Opus 5 Opus 5 ÷ Sonnet 5 B $1.553 $2.018 1.30 倍 D $1.234 $1.471 1.19 倍 こう見ると、Claude Opus 5 のほうがコスパが良いようにも感じられてきます。Claude Opus 5 とSonnet 5 の請求額（実費）がせいぜい1.30 倍程度なのであれば、 性能比で考えたときの Claude Opus 5 のコストパフォーマンスは群を抜いています。 結論 安いモデルは相応に推論を厚く取よう設計されており、その厚みは、出力トークンとして単価表の右端の列に乗ってきます。 割引は、割引された側が余分に考えることで一部追徴されている 、という構図です。 もっとも、今回の題材は 2 つとも標準ライブラリだけで書ける単一ファイルの実装課題で、既存コードの改修や大規模なリファクタリングでは傾向が変わりうるものです。品質自体は飽和してしまったため、難しい課題で品質差が開いたときにこの比率がどう動くのかも分かっていません。 また、 Fable 5 はeffortをmediumで運用することが望ましい ということが 公式に言及されて おり、今回の検証は非常に簡素なものであることを申し添えておきます。結論は 「トークン単価とタスクの難易度を見比べ、最適なモデル選択とeffort設定を心がけるように、軽量なモデルから試していくことが重要」 という、なんとも凡庸なものになってしまいそうです。 とはいえ、 「Claude Sonnet 5 で何度もラリーを重ねるよりは高コスパな Claude Opus 5で一発で叶えてしまったほうが却って安い場合がありそうだ」 というのは重要な発見であったと感じています。 おわりに 今回の検証の結論は、 Claude Opus 5 のコストパフォーマンスが際立っている 、というものでした。請求は Claude Fable 5 の約 2 分の 1で済み、単価が半額であるだけでなく、出力トークンと思考の比率そのものが Claude Fable 5 を下回っています。 そのうえで、トークン単価の引き下げが請求額にそのまま届くわけではないことも分かりました。Claude Sonnet 5 の単価は Claude Opus 5 の 2.5 分の 1 ですが、請求は 1.79 〜 1.95 分の 1 にとどまりました。差の 2 割から 3 割は、厚い推論による消費量の増加で相殺されています。 一方で、Claude Opus 5 をClaude Code 経由で 1 週間ほど実務で使った体感としては、 業務ドメイン知識に基づく意思決定や判断が必要なケース、 /adviser コマンドで入れるエスカレーション先としては、Opus 5 の出力精度（柔軟な思考力・判断力）はやや物足りない 印象を受けました。そのため、完全な上位互換になっているとは言えないでしょう。 とは言え、 日常使いにおいては Opus 5 で必要充分かそれ以上のパフォーマンスを得られる。また、 Opus 5 で充分なタスクに対する Fable 5 の使用は、コストパフォーマンス的に極めて悪手である ということは、Claude Enterprise プランを導入している弊社の面々にも強調しておきたいところです。 センセーショナルな見出しでモデルを選ぶのではなく、堅実なコストパフォーマンスを見せるOpus 5 を、社内でも積極的に広めていこうと思いました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kikuchi.s レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

1. はじめに こんにちは、事業支援部の江夏秀俊です。 当部の業務の一つに、事業部門の社内審議を支援する事務局としての役割があります。具体的には、審議案件の内容確認や全社審議の申し込み受付、審議会の開催調整（日程調整やレビューワーアサイン）、審議資料の確認・管理を通し、適切な投資やプロジェクトの品質を維持する役割を担っています。 以前の事業部制では、自分の担当事業部のレビューワーとなる役職者や適用されるルールを把握していれば問題ありませんでした。 2025年より統括本部制が敷かれ、各事業部に配置されていた事務局も統合されました。組織改編に伴い、事務局担当者の守備範囲が事業部から会社全体に拡大され、正しい審議体制の作成だけで1件あたり30分もかかる状態となりました。 そこで、全社の厳格なガバナンスを維持しつつ、事務局メンバーに負担をかけない運用設計を目指し、Excelを用いた体制作成の効率化に取り組みました。 本記事では30分かかっていた作業を5分に短縮した取り組みについてご紹介します。 2. 課題：紐解いてわかった「125通り」のルール 当社の社内投資審議は、以下の条件の組み合わせで決裁ルートや招集すべきレビューワーが細かく変動します。 なお、以下のルールについては社外秘情報のためデフォルメさせております。 案件の種別 (研究開発/ソフトウェア新規製品開発/ソフトウェア機能強化/etc)　・・・5通り 予算内 / 外　・・・2通り 付議区分（新規/終了/など）　　・・・4通り 投資回収の未達有無　・・・2通り 後続で○円超の開発有無　・・・2通り 予算転用(○円超)有無　・・・2通り 提案金額（○円超など数段階）　・・・8通り 申請フォームの情報とルールが準備されていて、ロジックと時間があれば適切な体制を導出できそうに思われがちですが、 全社規模のルールを目視で確認するには複雑であり、ルールの見落としや解釈の相違に伴う人的ミスのリスクも伴います。 単純な掛け算で考えると5 x 2 x 4 x 2 x 2 x 2 x 8 = 2560 通りとなりますが、「研究開発案件は投資回収の未達有無に関する分岐が存在しない」「特定の付議区分では予算転用が発生しない」「提案金額の段階は案件の種別によって異なる」など、条件の組み合わせによって存在しないケースがあります。そこで、社内ガイドラインをはじめとする各種規定を体系的に整理し、有効なケースのみを洗い出しました。その結果、「125通り」となることがわかりました。 3. 技術選定：なぜExcelの標準機能を選んだのか ルールのシステム化にあたり、Excelの標準機能（関数）、VBA、生成AIの3つを比較検討しました。 手法 再現性 導入性 拡張性 保守性 判定 Excel標準機能(関数) ◎ ◎ △ ○ 採用 VBA / マクロ ◎ △ ◎ △ 不採用 生成AI △ ◎ ○ △ 不採用 (※AIの評価は2025年1月時点の自社検証結果です) AIを見送った理由：再現性の担保 当社は全社員がセキュリティを担保したまま生成AIを使える環境が整っています。 当初は、申請情報に加えて社内ガイドラインや審議ルールを生成AIへ入力し、案件ごとに適切な審議体制を提案させる活用を検討しました。 しかし、当時の検証では、ルールに則った体制の導出が安定してできませんでした。 社内投資審議という厳格なガバナンスが求められる領域においては、ハルシネーションによって誤ったレビューワーを導出してしまうリスクを無視することができませんでした。 そのため、再現性を確実に担保できるロジックベース（Excel関数）を採用するという判断を下しました。 なお、現在(2026年7月)のAIの能力は当時より大きく向上しており、AI適用に向けて現在も検討を進めています。 VBAを見送った理由：例外処理への柔軟な対応と学習コスト VBAを使えば完全な自動化も可能ですが、今回は関数と一部の手作業を残す「半自動化」を選択しました。 実務では「本来の基準では呼ばなくてもいいが、特別に参加してほしい」といった、イレギュラーな参加者の手動追加が発生します。 すべてを自動化するのではなく、現場の運用に不可欠な例外的な対応の余白を残すための判断です。 また、Excel関数と比較した場合のVBAの学習コストなども鑑みて見送りました。 4. ツールの全体像：4つのシートで構成されるアーキテクチャ 実装したツールの全体イメージは以下のとおりです。なお、本ツールは社外秘のため、大幅にデフォルメしております。 構成されるシートは以下の4つです。④がメインのシートで他の①②③を参照する構成となっていますが、実際にユーザが操作/閲覧するのは④上だけで済むようなUIとしています。 *関数の詳細なロジックについては、次の「5.実装の工夫」にて詳しく解説します ①申請情報シート ②125パターン審議体制マトリクス ③レビューワーテーブル ④ 完成体制シート 以下それぞれのシートについて説明します。 ①申請情報シート こちらは申請情報シートとなります。ここには申請番号ごとに各種申請に関する詳細情報が記載されています。 Webシステムで申請を受け付けており、ここにデータが蓄積されていきます。 *説明しやすいよう転置していますが、実際のシートでは行方向にデータが並んでいます。 ②125パターン審議体制マトリクス 分析した125パターンの分岐ルールをExcelのテーブルとして定義しました。 裏側に「125パターン審議体制マトリクス」と「レビューワーテーブル」（③で説明）という巨大なテーブルを用意し、XLOOKUP関数でテーブルを参照する構造としています。 これにより、申請データから正しい決裁区分とレビューワー側のロールを引き当てます。 ③レビューワーテーブル レビューワーは技術本部ごとに担当役員、本部長、評議員候補、PMOなどが設定されており、それぞれの役割に応じた権限でレビューを行います。 ここでは各本部における各種レビューワーを定義しています。 ④完成体制シート こちらは完成体制シートです。事務局担当者はこの画面で申請番号と評議員番号（黄色いセル）のみを入力します。 評議員番号は「評議員選定の注意事項」を参照しながら「評議員(一覧)」から選びます。 これだけで審議体制が生成されます。あとは、図の右下に記載のExcelのセル（会議主題、会議本文、To宛先、Cc宛先）の4か所をコピーしてOutlook予定表に貼り付ければ体制が完成します。 もし、補足したい事項（内容、ccで加えたい宛先）があればそのときに手動で追加できるよう柔軟な仕様にしています。 *関数の詳細なロジックについては、次の「5.実装の工夫」にて詳しく解説します 5. 実装の工夫：業務に寄り添う設計 ここでは特に工夫したところを２つピックアップしてご紹介します。 工夫1：関数を用いた高度な配列処理 こだわりを持って工夫したのが、 技術本部ごとに用意された評議員リストから、必要な人物だけをピンポイントで抽出する 処理です。 レビューワーとして参加する評議員だけは本部ごとに異なる選定ルールに則り、優先度が高い人からスケジュールを確認しながら選定する運用としています。そのため、評議員一覧から番号を手で入力する工程がやりやすいように手動で選定する仕様としています。 たとえば、対象者の評議員番号として「1,3」が入力された場合、レビューワーテーブル記載の該当する技術本部の評議員一覧「評議員A、評議員B、評議員C、評議員D、評議員E」から、1番目と3番目の評議員Aと評議員Cがスピル(複数セルに結果が自動展開される機能)で抜き出されます。なお、入力セル側は半角カンマとしていますが、一覧側の区切り文字は氏名を入力する欄なのでそれに合わせて全角読点としています。 これを1つの関数で実現したのが以下の数式(イメージ)です。数式の設計にはAI（Copilot）を活用しています。 =IF(OR(評議員要フラグ="-",技術本部=""),"", LET( 評議員一覧, TEXTSPLIT(XLOOKUP(技術本部, レビューワーテーブル!U:U, レビューワーテーブル!Z:Z), "、"), 選定評議員番号, TEXTSPLIT(評議員番号入力セル, ","), 選定評議員, MAP(選定評議員番号, LAMBDA(i, INDEX(評議員一覧, VALUE(i)))), IF(TEXTJOIN("", TRUE, 選定評議員)="", "-", 選定評議員) )) 実際のシート名、変数名などは社内規定に合わせて変更しています XLOOKUPで候補者を取得し、TEXTSPLITで配列化。 さらに比較的新しいExcel関数であるMAPとLAMBDAを使い、配列をループ処理させて特定の人物を動的に抽出しています。複数名をアサインできる仕組みと評議員番号用のセルを1か所に集約させることを両立することに苦労しました。メンテナンス性と属人化の排除を考慮し、関数だけで完結させることにこだわりました。また、LET関数を用いることでネスト化を回避、変数名にあえて日本語を用いることで可読性を向上させました。 Microsoft 365環境にて動作確認しています 工夫2：図形オブジェクトによる注意書き 先ほども述べましたが、評議員の選定ルールは本部ごとに異なります。必要人数、必須参加者、案件の性格、レビューイーの所属に応じて対応が必要となります。 そこで、125通りの判定ルールとは独立した仕組みとして、画面上に評議員選定における注意事項を記した表示が切り替わるよう図形によるオブジェクトを取り入れました。 別ファイルのマニュアルを開く手間を省き、必要な情報をその場で確認できるようにする、業務担当者へのちょっとした配慮です。 近くのセルにルールを記載する方法も考えましたが、記載内容の量が多く、セルへの収録が困難だったため、任意の位置に移動できる図形オブジェクトを採用しました。 図形の数式バーにセル参照を直接入力することで実装しています。 該当のセルには以下のような数式(イメージ)が記載され、本部ごとに切り替わるようになっています。 図形の数式バーには =A1 と入力し、A1セルには以下の数式を入力します。 ="■評議員選定の注意事項"&CHAR(10)&XLOOKUP(本部名,レビューワーテーブル!本部列,レビューワーテーブル!評議員選定ルール列) 実際のシート名、変数名などは社内規定に合わせて変更しています 6. まとめ 今回の取り組みにより、作業時間が30分から5分に短縮され、組織表やガイドラインを照合する作業からも大幅に解放され、人的ミスの大幅削減にも貢献しました。 ルールの判定は確実なExcel関数に任せ、関数の作成にはAIを頼る。 このような「適材適所」が現時点でのベストプラクティスだと感じています。次のステップとして、AIもうまく活用しながら、より組織の変化に対応できるようなツールに進化させていければと考えています。 私たち事務局は、会社の円滑な意思決定とガバナンスを根底から支える存在として、今後も全社の統制と柔軟性を両立する仕組みづくりに挑戦していきたいと思います。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @koka.hidetoshi （ Shodo で執筆されました ）

こんにちは！クロスイノベーション本部 リーディングエッジテクノロジーセンターの松清です。 最近では、普段システム開発を行わない方でも、業務でAIエージェントを活用したり、ツールを用いて自身でAIエージェントを構築したりする機会が増えてきたのではないでしょうか。 Copilot Studio は、簡単にAIエージェントを作成できるツールであり、SharePoint サイトや Teams チャネルなどの Microsoft 365 製品とも連携しやすいため、すでに業務で活用されている方も多いと思います。 一方で、人事・経理・情報システムなど、用途ごとに Copilot Studio のエージェントを作成していくと、「AIエージェント同士が協力して仕事を進める仕組み」をどのように実現すべきか悩むケースもあるのではないでしょうか。 せっかく専門性の高いエージェントを作成しても、それぞれが独立して動くだけでは活用の幅は限定的です。複数のエージェントが連携し、適切なエージェントへ処理を引き継いだり、順番に協力して業務を進めたりできるようになると、より実務に近いAI活用が実現できます。 本記事では、既に作成済みの Copilot Studio エージェントを、別のエージェントから呼び出して活用することを前提に、2つの構成パターンを紹介します。それぞれのパターンの強みと注意点、適した活用シーンを整理しながら、どのような場面で使い分けるべきかを解説します。 Copilot Studioで可能な複数エージェントの連携パターン 既に作成済みの専門エージェントを別のエージェントから呼び出して活用する方法として、以下の2パターンを紹介します。 パターン1：エージェント追加によるAIオーケストレーション パターン2：フローを介したエージェント実行制御 パターン1：エージェント追加によるAIオーケストレーション パターン1は、既に公開済みの専門エージェントをメインエージェントに追加し、ユーザーの入力内容に応じて、AIが適切なエージェントへ処理を委任する方法です。 イメージとしては、「社内問い合わせの総合受付」を AI が担う構成です。利用者は問い合わせ先を意識する必要がなく、自然な言葉で質問するだけで、AI が人事・経理・情報システムなどの専門エージェントの中から適切な担当者を選び、回答へつなげてくれます。 Copilot Studio では、メインエージェントに公開済みの Copilot Studio エージェントを接続し、メインエージェントから専門エージェントを呼び出す構成を作成できます。 ここでは、例として以下の専門エージェントが作成済みである前提で、これらをメインエージェント「社内問い合わせ統合エージェント」に追加する流れを紹介します。 人事問い合わせエージェント 経理問い合わせエージェント 情報システム問い合わせエージェント 設定手順 1. メインエージェントを新規作成する まず、複数の専門エージェントをまとめるためのメインエージェントを新規作成します。 今回は例として、「社内問い合わせ統合エージェント」を作成します。 2. ［エージェント］タブを開く 作成したメインエージェントの［エージェント］タブを開き、［+追加］を選択します。 3. 追加する専門エージェントを選択する メインエージェントから呼び出したい専門エージェントを選択します。 今回は例として、以下のような専門エージェントが作成済みであるとし、それらを追加します。 人事問い合わせエージェント 経理問い合わせエージェント 情報システム問い合わせエージェント 4. 専門エージェントの説明を設定する 追加する専門エージェントの説明を設定します。 この説明は、メインエージェントがどのタイミングでその専門エージェントを呼び出すかを判断する材料になります。 5. メインエージェントの説明・指示を設定する メインエージェント自体にも、どのような問い合わせを受け付け、どの専門エージェントへ委任するのかが分かる説明・指示を設定します。 6. テスト実行する メインエージェントをテスト実行し、問い合わせ内容に応じて適切な専門エージェントが呼び出されるか確認します。 7. メインエージェントを公開する 動作確認後、問題がなければメインエージェントを公開します。 このパターンの強みと注意 このパターンの強みは、トピックやワークフローを細かく作り込まずに、ユーザーの入力内容に応じて適切な専門エージェントへ委任できる点です。メインエージェントに専門エージェントを追加し、それぞれの説明を設定することで、複数エージェントの連携を比較的容易に始められます。 そのため、ユーザーの問い合わせ内容が多様で、あらかじめカテゴリを細かく決めきれない場合や、自然な会話の中で適切な専門エージェントへつなぎたい場合に向いています。既存の専門エージェントを大きく変更せずに連携できるため、複数エージェントの活用をまず試してみたい場合にも導入しやすい構成です。 一方で、呼び出す専門エージェントの選択はAIの判断に依存します。Copilot Studio の生成オーケストレーションでは、エージェントやツールの説明をもとに、ユーザーの意図に合った呼び出し先が判断されます。そのため、専門エージェント同士の担当範囲が重なっていたり、説明が曖昧だったりすると、意図したエージェントが選ばれにくくなる可能性があります。各専門エージェントの説明には、「何を担当するエージェントなのか」「どのような問い合わせで呼び出すべきなのか」を具体的に記載することが重要です。 さらに、メインエージェントがユーザーの意図を判断したうえで専門エージェントへ委任するため、構成や問い合わせ内容によっては応答時間が長くなる可能性があります。特に、複数のエージェントや外部連携を組み合わせる場合は、実際の利用を想定したテストで、呼び出し先の選択精度や応答時間を確認しておくことが重要です。 パターン2：フローを介したエージェント実行制御 パターン2は、メインエージェントからフローをツールとして呼び出し、そのフロー内で複数の専門エージェントを決められた順番で実行する方法です。 パターン1では、メインエージェントがAIオーケストレーションによって、ユーザーの入力内容に応じた専門エージェントを選択します。一方、この方法では、実行する専門エージェントとその順序をフロー内であらかじめ定義できます。 ここでは例として、社内問い合わせの中でも、人事観点の確認後に経理観点の確認が必要になるケースを考えます。具体的には、以下の2つの既存エージェントをフロー内で順番に呼び出す構成を紹介します。 人事問い合わせエージェント 経理問い合わせエージェント この構成では、まず人事問い合わせエージェントを実行し、その結果を次の経理問い合わせエージェントに引き継ぎます。このように、ある専門エージェントの回答を前提として、次の専門エージェントを実行したい場合には、フローを介して実行順序を明示的に制御する構成が有効です。 1. フローを呼び出すメインエージェントを作成する まず、ユーザーからの依頼を受け付け、フローを呼び出すためのメインエージェントを作成します。 今回は例として、「社内手続き確認エージェント」を作成します。 このエージェントは、ユーザーからの依頼内容を受け取り、必要に応じてフローをツールとして呼び出す役割を持ちます。 2. メインエージェントのツールとしてワークフローを追加する 作成したメインエージェントの［ツール］メニューから、［ツールを追加する］を選択します。 次に、［ワークフロー］を選択し、新しいワークフローの作成を開始します。 エージェントから呼び出されるワークフローに必要なトリガーは、あらかじめ設定された状態で作成されます。 3. 入力パラメーターを設定する ワークフローのトリガーに、フローへ渡す入力を設定します。 今回は、ユーザーからの依頼内容を受け取るため、以下の入力を設定します。 入力名： request 種類：テキスト 説明：ユーザーからの依頼内容 以降のアクションでは、この request を動的コンテンツとして利用します。 4. 人事問い合わせエージェントを呼び出す トリガーの下にアクションを追加し、［エージェントを実行して待機する］を選択します。 呼び出すエージェントとして「人事問い合わせエージェント」を指定します。 次に、［詳細パラメーター］を開き、［メッセージ］を追加します。［メッセージ］は、以下のように設定します。 以下の問い合わせについて、人事観点で確認すべき事項を整理してください。 ユーザーからの依頼内容： （動的コンテンツから request を挿入） 5. 経理問い合わせエージェントを呼び出す 続けてアクションを追加し、同じく［エージェントを実行して待機する］を選択します。 呼び出すエージェントとして「経理問い合わせエージェント」を指定します。 次に、［詳細パラメーター］を開き、［メッセージ］を追加します。［メッセージ］は、以下のように設定します。 以下の問い合わせについて、経理観点で確認すべき事項を整理してください。 また、以下の人事観点の確認結果も踏まえて、ユーザーに案内すべき経理手続きを整理してください。 ユーザーからの依頼内容： （動的コンテンツから request を挿入） 人事観点の確認結果： （動的コンテンツから、人事問い合わせエージェントの lastResponse を挿入） これにより、人事観点の確認結果を踏まえたうえで、経理観点の確認結果を取得できます。 6. 実行結果をメインエージェントへ返す 最後に、［Respond to the agent］アクションを設定し、ワークフローの実行結果をメインエージェントへ返します。 出力の種類には［テキスト］を選択し、出力名を result とします。 result の値には、前の手順で実行した人事問い合わせエージェントと経理問い合わせエージェントの回答本文を差し込みます。 設定例は以下のとおりです。 人事観点： （動的コンテンツから、人事問い合わせエージェントの lastResponse を挿入） 経理観点： （動的コンテンツから、経理問い合わせエージェントの lastResponse を挿入） これにより、人事問い合わせエージェントと経理問い合わせエージェントの回答を、1つのテキストとしてメインエージェントに返すことができます。 7. ワークフローを保存・公開する 設定が完了したら、［公開］を選択してワークフローを公開します。 8. 公開したワークフローをメインエージェントのツールとして追加する ［ツールを追加する］を選択し、［ワークフロー］から、作成した「社内手続き確認フロー」を選択して追加します。 追加後、ツールの詳細画面で［名前］と［説明］を設定します。 ［名前］には、メインエージェントが用途を判断しやすい名称を設定します。今回は、フロー名と同じく以下のように設定します。 社内手続き確認 ［説明］には、このツールをどのような依頼で使用するのかを記載します。例えば、以下のように設定します。 人事観点と経理観点の両方を確認する必要がある社内手続きについて、まず人事問い合わせエージェントで確認し、その結果を踏まえて経理問い合わせエージェントで確認するためのフローです。年次有給休暇、フレックスタイム制度、交通費精算、出張旅費など、人事・経理をまたぐ問い合わせで使用します。 ワークフローを追加しただけでは、メインエージェントが必ずそのワークフローを呼び出すとは限りません。そのため、［名前］や［説明］には、メインエージェントがこのツールを使用すべき場面を判断しやすい内容を設定します。 9. メインエージェントで動作確認する メインエージェントをテスト実行し、作成したワークフローが呼び出されるか確認します。 10. メインエージェントを公開する 動作確認後、問題がなければメインエージェントを公開します。 このパターンの強みと注意点 このパターンの強みは、決められた順序で専門エージェントを呼び出すことで、固定された業務フローを安定して実行できる点です。 今回の例のように、人事観点で確認した内容を踏まえて経理観点の案内を行いたい場合には、まず人事問い合わせエージェントを実行し、その結果を次の経理問い合わせエージェントに引き継ぐ、といった流れを明確に定義できます。 また、問い合わせ対応に限らず、会議後に議事録を作成し、タスクを洗い出し、担当者ごとにメールを送信するといった、一連の業務フローを自動化する用途にも活用できます。複数の処理を決まった順番で実行したい場合に適した構成です。 一方で、ワークフローを追加しただけでは、メインエージェントが必ずそのワークフローを呼び出すとは限りません。そのため、ツールの［名前］や［説明］には、どのような依頼で使用するのかを具体的に記載する必要があります。メインエージェントが利用場面を判断しやすいように、対象となる業務や問い合わせの例を明確にしておくことが重要です。 各パターンの比較と活用シーン ここまで、既に作成済みの専門エージェントを別のエージェントから呼び出す方法として、以下の2パターンを紹介しました。 パターン1：エージェント追加によるAIオーケストレーション パターン2：フローを介したエージェント実行制御 それぞれの特徴を整理すると、以下のようになります。 観点 パターン1：AIオーケストレーション パターン2：フローを介した実行制御 専門エージェントの呼び出し方 メインエージェントがユーザーの入力内容をもとに、AI判断で専門エージェントを呼び出す メインエージェントがフローを呼び出し、フロー内で専門エージェントを実行する 実行順序 AIの判断に委ねる フロー内で明示的に指定する 向いている用途 社内問い合わせ、FAQ、ナレッジ検索など、問い合わせ内容に応じて柔軟に振り分けたい用途 複数エージェントの順次実行、定型的な確認処理、決まった流れで処理したい用途 強み ユーザーの入力内容に応じて、柔軟に専門エージェントへ振り分けられる 実行するエージェントと順序を固定でき、処理の流れを明確に制御できる 注意点 呼び出す専門エージェントの選択がAIの判断に依存する フローの設計・保守が必要になる ユーザーの問い合わせ内容が多様で、あらかじめ処理の流れを細かく決めきれない場合は、パターン1が向いています。 例えば、社内問い合わせのように、人事・経理・情報システムなど複数の問い合わせ先があり、ユーザーの自然な入力内容に応じて適切な専門エージェントへ振り分けたい場合に適しています。 一方で、複数の専門エージェントを必ず決まった順番で呼び出したい場合は、パターン2が向いています。 例えば、「人事観点で確認した後に経理観点で確認する」「議事録を作成した後にタスクを抽出する」といったように、前の処理結果を次の処理に引き継ぎながら進めたい場合に適しています。 既存の専門エージェントを活かしながら、ユーザーの入力内容に応じて柔軟に振り分けたい場合はパターン1、処理の順序を明確に制御したい場合はパターン2、という観点で使い分けるのが適切だと考えられます。 おわりに 本記事では、既に作成済みの Copilot Studio エージェントを別のエージェントから呼び出して活用する方法として、以下の2つのパターンを紹介しました。 エージェント追加によるAIオーケストレーション フローを介したエージェント実行制御 Copilot Studio の魅力は、単に1つのAIエージェントを作ることだけではなく、複数のエージェントを組み合わせて、より実務に近い業務遂行の仕組みを構築できる点にもあります。 今後、AIエージェントの活用が進むにつれて、「専門エージェント同士が協力して仕事を進める構成」はますます重要になっていくでしょう。 本記事が、皆さまのAIエージェント活用の幅を広げるきっかけになれば幸いです。 参考資料 エージェントからエージェント フローを呼び出す 生成オーケストレーション機能を適用する 他のエージェントの概要を追加 エージェント フローまたはワークフローをツールとしてエージェントに追加する エージェント フローとワークフローの概要 エージェントの活動を確認する 執筆： @matsukiyo.ryota レビュー： @kinjo.ryuki （ Shodo で執筆されました ）

こんにちは。クロスイノベーション本部の平岡です。 弊社のAzureクラウドSOC（以下Azure SOC）では、Azure環境のセキュリティ設定の可視化と改善、およびセキュリティインシデントの早期発見と調査支援を行っています。 私はAzure SOC運営メンバーとして主にMicrosoft Defender for Cloudを活用し、Azure環境のセキュリティ設定の監視を行っています。 前回書いた ブログ では、Azure SOCで活躍している便利なサービスの一部として、Microsoft Defender for CloudのCSPM機能とCWP機能の概要を紹介しました。 今回はCWP機能の一つであるセキュリティアラートを、メールもしくはMicrosoft Teams（以下Teams）の任意のチャネルに自動通知する方法についてご紹介したいと思います。 セキュリティアラートをメールで通知したい場合 Microsoft Defender for CloudのCWP（クラウドワークロード保護）を有効にすることで、セキュリティアラート画面上に、クラウド環境内で脅威が検知されるようになります。詳細は 前回ブログ をご一読ください。 セキュリティアラートはMicrosoft Defender for Cloudの通知設定もしくは、Azure Monitorのアラート設定を行うことで、メールで通知できます。 特にMicrosoft Defender for Cloudの通知設定は非常に簡単に設定できるため、CWPを活用している場合は設定することをお勧めします。 Microsoft Defender for Cloudのメール通知設定 メールの受信者にはAzure RBACの一部ロールを設定するか、直接メールアドレスを設定できます。 例えば「所有者」ロール選択時には、「所有者」権限が割り当てられている全員宛にMicrosoft Defender for Cloudからメールを受け取ることができます。 Azure Monitorのアラート設定 Azure Monitorのアラート設定では、より詳細に条件を設定できます。 セキュリティアラートをTeamsの任意のチャネルに通知したい場合 単一サブスクリプションを管理している場合はメール通知で十分だと思いますが、Azure SOCではAzure Lighthouseを利用し、弊社内の複数プロジェクトのサブスクリプションのセキュリティ情報を集約しています。 そのため、セキュリティアラート発出時には、サブスクリプション管理者に即時で対応してもらうために、個々のサブスクリプション連絡用チャネルに即時でTeamsの通知を飛ばしたいと考えました。 やりたいこと Microsoft Defender for Cloudのセキュリティアラート発出をトリガーとして、Logic Appsを起動する Excelファイル内のテーブル情報を取得する セキュリティアラートに紐づくサブスクリプションIDと、Excelファイル内のサブスクリプションIDを突き合わせて、該当のTeamsのグループIDとチャネルIDを取得する 取得したグループIDとチャネルIDに該当するTeamsのチャネルに通知する Microsoft Defender for Cloudでワークフローの自動化設定を行う セキュリティアラートが想定のチャネルに投稿されることを確認する 1~4はAzure Logic Apps（以下Logic Apps）で設定し、5はMicrosoft Defender for Cloudで設定します。 最後にサンプルアラートを出して、想定したチャネルに投稿されることを確認します。 Logic Appsの設定 Logic AppsはAzure上で提供されるクラウドベースのワークフローの自動化サービスです。 さまざまなアプリやサービスをつなぎ、業務プロセスを自動化できます。 特徴 ローコード/ノーコードで構築可能 トリガーとアクションの組み合わせで定義 多種多様のコネクタが利用可能(Teams、Microsoft Defender for Cloud、Microsoft 365、Salesforce、X(Twitter)等) 1~4のやりたいことをトリガーとアクションを組み合わせて定義します。 1. Microsoft Defender for Cloudのセキュリティアラート発出をトリガーとして、Logic Appsを起動する メニューの[ロジックアプリデザイナー]を選択すると、[トリガーの追加]ボタンが表示されます。検索欄に"Defender for Cloud"と入力すると、セキュリティアラート以外にもレコメンデーション（推奨事項）や規制コンプライアンスの発出がトリガーとなるコネクタがあることがわかります。 今回は、「Microsoft Defender for Cloud の警告が作成またはトリガーされた場合」トリガーを選びます。 2. Excelファイル内のテーブル情報を取得する トリガーを作成するとアクションを追加できるようになります。 [アクションの追加]ボタンを押下し、検索欄に"Excel"と入力すると、さまざまな種類のExcelコネクタが表示されます。 今回は、「表内に存在する行を一覧表示」アクションを選びます。 Teams内に格納しているExcelファイルにアクセスして、テーブルの情報を取得します。 ExcelファイルにはサブスクリプションID、Teamsのチャネル名、TeamsのグループID、TeamsのチャネルIDを記載しています。Excel内のデータ範囲は、あらかじめテーブルとして書式設定しておく必要があります。 3. セキュリティアラートに紐づくサブスクリプションIDと、Excelファイル内のサブスクリプションIDを突き合わせて、該当のTeamsのグループIDとチャネルIDを取得する [アクションの追加]ボタンを押下し、検索欄に"Filter array"と入力すると、紫のアイコンのビルトインアクションが表示されます。 （ビルトインアクションはタイトルの右横に青字で"Built-in"と表示されています） パラメータタブで、[FROM]にExcelファイルの"Value"を選択します。 [Filter Query]の左辺には動的なコンテンツからExcelファイル内のサブスクリプションID、右辺にはセキュリティアラートに紐づくサブスクリプションIDを選択して、一致する情報をExcelファイルから取得するように設定します。 4. 取得したグループIDとチャネルIDに該当するTeamsのチャネルに通知する [アクションの追加]ボタンを押下し、検索欄に"Teams"と入力し、"チャットまたはチャネルでメッセージを投稿する"チャネルを選択します。 パラメータタブで、[投稿者]は"フローボット"や"ユーザ"を選択できます。プライベートチャネルに投稿したい場合は"ユーザ"を選択しないとエラーになります。 [投稿先]は"グループチャット"または"チャネル"が選択できます。 [チーム]はExcelファイル内の"group_id"、[チャネル]はExcelファイルの"channel_id"を選択します。※"group_id"を選択することで、自動的にループ処理が追加されます。 [メッセージ]では提供したい情報を記載したり、特定の相手にメンションすることもできます。 For each処理のパラメータには"Filter array"の"Body"を選択します。 以上でLogic Appsの設定は完了です。 5. Microsoft Defender for Cloudでワークフローの自動化設定を行う Microsoft Defender for Cloudでワークフローの自動化設定を行います。 メニューで[ワークフローの自動化]を選択し、[＋ワークフロー自動化の追加]を押下します。 [ワークフローの自動化の編集]画面が表示されるため、トリガーの条件やLogic Appsを選択して保存します。 6. セキュリティアラートが想定のチャネルに投稿されることを確認する 最後にセキュリティアラートが想定のチャネルに投稿されることを確認します。 実際にセキュリティアラートを出すのはリスクがあるため、今回はMicrosoft Defender for Cloudの標準機能であるサンプルアラートを出してテストします。 サブスクリプションBのサンプルアラートを出してみます。 サブスクリプションBチャネルを確認すると、無事通知が投稿されていました。 まとめ 今回はMicrosoft Defender for Cloudのセキュリティアラートを、メールまたはTeamsのチャネルに投稿する方法をまとめました。 ローコード/ノーコードで利用できるLogic Appsで、他にも便利な自動化ツールを作成できそうです。 みなさんも是非Logic AppsとMicrosoft Defender for Cloudを組み合わせて活用してみてください！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @hiraoka.eri2 レビュー： @ozaki.hisanori （ Shodo で執筆されました ）

はじめに 金融IT本部 3年目の坂江 克斗です。 re:Invent 2025 で公開されたFrontier Agentの1つとして AWS Security Agent が発表され、3月には AWS Security Agentのペネトレーションテストが一般公開 されました。 AWS Security Agentは、開発フローにセキュリティを統合する DevSecOps において、その「Sec（セキュリティ）」を担うようなサービスです。 本記事では、AWS Security Agent 全体の使用感を、コンソール操作とCICDへの組み込みイメージも含めて紹介します。 ※本記事は2026年6月時点の情報です。 本記事執筆時の2026年6月17日に、 AWS Continuum が発表され、AWS Security Agent のペネトレーションテスト・コードスキャン機能は「Continuum for penetration testing」「Continuum for code scanning」（プレビュー）として Continuum の一部にもなりました。本記事の操作内容は引き続き参考になりますが、AWS Security Agent の名称や提供形態は今後変わっていく可能性があります。 はじめに Frontier Agent とは AWS Security Agent の概要 全体像 コスト クォータ データ保護 テスト・レビュー コンソール画面 実際に試してみる 管理者側の設定手順 AWS Security Agent アプリケーションの作成・エージェントスペースの作成 【AWS Security Agent アプリケーションが既に存在する場合】エージェントスペースだけの作成 セキュリティエージェントを使用可能な開発者の登録 ターゲットドメインの登録 リポジトリの統合 セキュリティ要件 コードレビューの有効化 ペネトレーションテストの有効化 開発者用コンソールの確認 開発側の実行手順 設計レビューの実行 コードレビューの実行 脅威モデルの実行 ペネトレーションテストの実行 レポートの確認 デザインレビュー 脅威モデル コードレビュー・ペネトレーションテスト CI/CDへの組み込み CLIコマンドの基本構造 共通： AWS 認証（OIDC） develop マージ時： コードレビュー stg デプロイ完了後： 軽量ペンテスト（DAST・対象を絞る） リリース時 / 定期： フルスコープのペネトレーションテスト 設計ドキュメント更新時： デザインレビュー（脅威モデリング） まとめ おわりに Frontier Agent とは 少し前になりますが、2025年のre:Inventにて「フロンティアエージェント（Frontier Agent）」という新しいカテゴリのAIエージェントが発表されました。 フロンティアエージェント とは、 自律的に動作する開発チームの拡張機能 として位置づけられたAIエージェントです。 個々のタスクをサポートする従来の AI アシスタントとは異なり、フロンティアエージェントはチームの拡張機能として機能し、多様なユースケースにわたって包括的な成果をもたらします。 AWSが定義するフロンティアエージェントには、以下の3つの特徴があります。 自律的 — 人間が常に介入しなくても、独立して動作します スケーラブル — 大規模なスケーリングにより、複数タスクを同時実行します 長時間実行 — 24時間365日、継続的に動作できます 2025年re:Inventで発表されたフロンティアエージェントは以下の3種類です。 エージェント 役割 AWS Security Agent 仮想セキュリティエンジニア。設計・コード・稼働中アプリを横断してセキュリティを担保する AWS DevOps Agent 仮想SREメンバー。インシデントのトリアージや根本原因分析、復旧を自律的に行う Kiro autonomous agent 仮想開発者。仕様書からコード生成・テスト・デプロイまでを担う 中でも今回は、インフラ構築の文脈で特に気になった AWS Security Agent を調査しましたので、その仕組みをまとめます。 去年のre:Invent直後に宮崎さんが AWS re: Invent2025で登場した3つのFrontier Agentsの1つである「AWS DevOps Agent」を触りつつ、概要について整理してみる。 という記事を書いていますので、気になる方はぜひご覧ください。 AWS Security Agent の概要 全体像 AWS Security Agentは機能としては、 SAST（Static Application Security Testing）・ DAST（Dynamic Application Security Testing） ・ペネトレーションテスト を単一のエージェントに統合し、 設計ドキュメントからソースコード・IaC・脅威モデルまでを取り込んでアプリの全体像（コンテキスト）を把握 することで、個々の脆弱性の連鎖まで含めた精度の高い検出と実用的な修復提案を実現するサービスです。 Security Hub/GuardDuty/Inspector などによる従来の事後的なセキュリティ調査では、本番デプロイ後に問題が見つかるため、設計やコードに起因する脆弱性ほど手戻りが大きくなりがちです。こうした背景から、 開発からデプロイまでのフローの早い段階にセキュリティのチェックを寄せる「シフトレフト」や、それを開発プロセスに組み込む「 DevSecOps 」 が重視されるようになってきました。AWS Security Agentは、この考え方を踏まえたサービスとなります。 DevOpsによって開発サイクルが高速かつ高頻度で回るようになった一方、セキュリティが従来どおりの体制のままでは開発スピードに追いつけません。この課題に対して生まれたのが DevSecOps で、開発初期からセキュリティを考慮するシフトレフトの動きを取りつつ、DevOpsの効率性を損なわないようにセキュリティレビュー等を自動化に組み込むことが重視されます。 AWS Security Agentは、大まかに以下の構成となっています。 設計レビュー（デザインレビュー） ・ コードレビュー ・ 脅威モデリング ・ ペネトレーションテスト という4つの作業を行うことができ、各レビュー・テストにおいては、管理側・開発側でコンソールを切り替えることができます。 そのため、開発側は作業中に管理側を意識する必要がなく、不要に管理設定を変更してしまうことを防げます。 コスト コストについては、現在のところ ペネトレーションテストの料金 のみが公開されており、1タスク時間あたり50ドル、かつ初回は2か月間・最大200タスク時間分が無料となっています。 AWS 公式ドキュメントによると、 平均的なアプリケーションテストには約 24 タスク時間かかり、包括的な侵入テストと修復にかかる費用は通常 1,200 ドル の見込みとのことです。 このタスク時間は、ペネトレーションテスト実行中にタスクごとに独立してエージェントが稼働していた場合、それぞれのエージェントの稼働時間を合算したものがそのままタスク時間に換算されます。 クォータ Service Quotas より、各レビューやテスト、連携可能なリソース数などに上限が設定されています。ただし、AWSサポート経由で申請することで上限を変更できます。 データ保護 アップロードするドキュメントなどのデータは、既定でAWSマネージドキーにより暗号化され、任意でカスタマーマネージドキー（CMK）を指定して自社で鍵を管理することも可能です。 S3・CloudWatch Logs・Secrets Managerを連携する際も、CMKで暗号化したものを渡して使用できます （各リソースのKMSキーポリシーと、サービスロールへの復号権限の設定が必要）。 ただし、 CMKを指定できるのはリソース（エージェントスペースや統合）の作成時のみで、既存リソースへの後付けや鍵の差し替えはできない点に注意が必要です （CMKで運用する場合はリソースの再作成が必要）。 テスト・レビュー 各テスト・レビューの内容を紹介します。詳細な設定方法や実際の動作については次の章をご参照ください。 なお、ポイントについてはドキュメントの内容に加えて私の解釈も含むため、セキュリティエンジニアの方のご意見もぜひ伺いたいです。 項目 概要 ポイント（普通のAI・既存ツールとの差分） 設計レビュー 設計書などのドキュメントを、組織で定義したセキュリティ要件（AWSマネージド／カスタムのガイドライン）に照らして自動レビューし、コードを書く前の段階で指摘。数分～数十分程度で完了。 セキュリティチームが基準を一元的に定義し、開発者側は変更・迂回できない（責務の分離）。組織横断で同じ基準を強制でき、結果が監査ログ・レポートとして残る。従来のSASTと異なり、（アプリ実行時のコンテキストを含まない）パターンマッチングではなく、 アプリの実際の動作・コンテキストを推論して脆弱性を検出 。 コードレビュー 連携したリポジトリやS3のコードを、セキュリティ要件に照らしてレビュー。フルリポジトリ／差分を選択でき、PRへのレビューコメントや自動修正PRまで対応。数分～数十分程度で完了。 設計レビューと同様。Gitにも統合でき、差分レビューなど使いやすい構成。 脅威モデル 攻撃者視点で潜在的な脅威を洗い出して分析。コード以外の信頼境界・権限設計・外部連携なども含め、広範な攻撃経路を整理。数分～数十分程度で完了。 実装上の問題を中心に見るコードレビューと異なり、アーキテクチャ全体のリスクを俯瞰。 ペネトレーションテスト （ 副作用を考慮し、検証環境での実施を推奨 ）稼働中のアプリに対し、ソースコードやドキュメントソースをもとにした多段階の攻撃シナリオで脆弱性を検出。再現手順・PoC・CVSS・修正PRまで提示。数時間～数十時間程度で完了。 従来の DAST と異なり、ブラックボックス的なアプローチではなく、 ソースコードやAPI仕様、設計書をもとにアプリの詳細なコンテキストを構築して検証 。テスト項目の設定によりスコープ調整も可能。 コンソール画面 操作するインターフェースは2層に分かれています。テストのスコープ・セキュリティ要件・リポジトリ統合などを設定する管理者コンソール（AWSマネジメントコンソール内）と、実際にレビューやテストを実行する開発者向けのWebアプリです。 開発者向けのWebアプリは、明示的にアクセス権限を設定でき、運用しやすい構成となっています。 実際に試してみる 本記事では、管理者側・開発者側それぞれの操作方法を紹介しながら、基本的な使用方法について共有します。 その他の詳細な設定について参照が必要な場合は、 AWS Security Agent ： User Guide をご参照ください。 前提として以下のリソースを準備します。 ドキュメント 設計書やAPI仕様（OpenAPIまたはSwagger）等 コードソース GitHub リポジトリ（今回はこちらで検証） S3バケット内のZIPファイル セキュリティ要件 上記のドキュメントやコードソースに対して準拠させたいガイドラインやポリシー ペネトレーションテスト用のエンドポイント情報（ 本番ではなくステージング環境を推奨 ） ターゲット情報（ 外部APIや決済処理、データの削除・更新等の副作用を伴うエンドポイントは除外 ） ドメイン パス VPC内のプライベートなアプリケーションの場合（Security Agent自身がENIを使用してアクセス） VPC ID サブネット ID セキュリティグループ ID アプリケーション接続時に認証情報が必要な場合 静的な認証情報（平文 or Secrets Managerシークレット） 動的な認証情報の生成方法をまとめたプロンプト Security Agent自体の運用管理 CloudWatch ロググループ（コンソールから作成する場合は自動作成されるため任意） IAM サービスロール（コンソールから作成する場合は自動作成されるため任意） KMSキー（デフォルトはAWSマネージドキーで管理されるため任意） 開発者に対応する IAM Identity Center のユーザ（Security Agentを使用可能なユーザを明示的に指定） 管理者側の設定手順 AWSコンソールのAWS Security Agentの画面より、管理者側の設定を行います。 AWS Security Agent アプリケーションの作成・エージェントスペースの作成 各レビュー設定に入る前に、AWSコンソールから全体で必要な設定をしておきます。 Security Agentのコンソール画面に遷移したら、「AWS Security Agentをセットアップ」ボタンを押下します。 AgentSpaceの設定を入力しつつ、AWSマネージドキーではなく、CMK（カスタマーマネージドキー）でデータを保護したい場合には、「Customize encryption settings (advanced)」チェックボックスにチェックを入れ、任意のCMKを紐付けてください。 タグについては、エージェントスペースタグがエージェントスペースに付与されるタグ、アプリケーションタグがAWS Security Agentアプリケーション自体に付与されるタグとなります。 また、 IAM Identity Centerもここで紐づくため、インスタンスを再作成すると連携が切れてしまう点に注意が必要です。（コンソールやCLI経由での更新不可です） 完了後、AWS Security Agent アプリケーションとエージェントスペースが作成されます。 【AWS Security Agent アプリケーションが既に存在する場合】エージェントスペースだけの作成 既にAWS Security Agentアプリケーションを作成済みの状態で、エージェントスペースのみ作成する場合は以下のように作成します。 Security Agentのコンソール画面に遷移したら、「最初のエージェントスペースを作成」ボタンを押下します。 AWSマネージドキーではなく、CMK（カスタマーマネージドキー）でデータを保護したい場合には、「Customize encryption settings (advanced)」チェックボックスにチェックを入れ、任意のCMKを紐付けてください。 作成画面の入力後、「作成」ボタンを押下します。 セキュリティエージェントを使用可能な開発者の登録 作成したエージェントスペース画面のウェブアプリタブにおいて、「ユーザの追加」を押下します。 IAM Identity Centerで設定したユーザーを選択し、「ユーザーを追加」ボタンを押します。 画面遷移後、ユーザーが追加されていることを確認できます。 ターゲットドメインの登録 サイドバーの「ターゲットドメイン」を押下し、ターゲットドメインのページから「ドメインを追加」ボタンを押下します。 ペネトレーションテストの対象となるドメイン・検証方法を選択し、「ドメインを追加」ボタンを押下します。 今回は検証方法としてDNS TXTレコードを指定しました。その他のHTTPルートやプライベートVPCの検証については「 Managed target domains used for penetration testing」 をご参照ください。 ターゲットドメインの追加完了後、「ワンクリック検証」を押下します。レコードの追加も含めマネージドに対応してくれるので、そのまま進めます。 検証が完了すると、ステータスが検証済みになります。 リポジトリの統合 サイドバーの「統合」から、「統合の追加」ボタンを押下します。今回はGitHubを選択して進めていきます。 設定画面に遷移したら、ステップ1より順に設定します。 ステップ2の「GitHubでAWS Security Agentを開く」を押下すると、GitHubアプリのインストール画面に遷移するのでインストールします。 この際、連携するリポジトリをアカウント内すべてにするか、特定のリポジトリに限定するかを選択できます。 インストールの完了後、ステップ3で認証するボタンを押下します。「認証が成功しました」という表示が出ることを確認します。 最後にステップ4で、登録名・アカウントタイプ・CMKによる暗号化を設定したら、「接続」ボタンを押下して完了です。 セキュリティ要件 コンソールサイドバーのセキュリティ要件より、マネージドまたはカスタムのセキュリティ要件を設定することができます。 セキュリティ要件は、設計レビューやコードレビューの際のガイドラインとなる設定であり、各セキュリティ要件項目と、それをまとめたパックの単位で管理を行います。 マネージドセキュリティ要件パックについては、 AWS managed security requirement packs またはコンソールから各設定値をご参照ください。 デフォルトではASA Base Packのみ有効化されています。 カスタム設定については、「Create security requirements pack」ボタンを押下してパックを作成した後に、パック内でセキュリティ要件を個々に設定します。 セキュリティ要件パックの作成後、セキュリティ要件の追加時には、手動での入力またはドキュメントを読み込ませて自動生成する方法を選ぶことができます。 マニュアル設定 の場合は、以下に示すように、条件を適用するシナリオ、具体的な違反内容、修正方法の提示について入力が必要となります。 ドキュメントをアップロードして自動生成する場合は、ファイルサイズにもよりますが、60KB程度のmdファイルを読み込ませて、数分程度で20個のセキュリティ要件が生成されました。 ただし、注意点として、 https://docs.aws.amazon.com/ja_jp/securityagent/latest/userguide/security-requirements.html にあるとおり、既存の要件を置き換えることになる点に注意が必要です。 Uploading new source documents regenerates all requirements for the pack. Any existing requirements, including ones you added manually, are replaced. コードレビューの有効化 コードレビューを有効にするボタンを押下して進めます。 接続された統合項目の追加ボタンを押下し、先ほど連携したGitHubアカウントを選択します。 今回は使用しませんが、S3バケットもコードの保存先として参照可能です。 アカウント内のリポジトリを選択し、「次へ」ボタンを押下します。 以下の設定を確認し、「接続」を押下します。 コードレビューコメント：PR作成時にレビューコメントを追加してくれる許可 PR修正：レビューやテスト後に脆弱性の箇所を自動でPR作成する許可 完了すると、コードレビューの設定画面に戻り、統合が追加されたことが確認できます。 その他の項目も確認し、「次へ」ボタンを押下します。 オプション設定画面に遷移したら、CloudWatchログとサービスロールを設定します。これらは事前に準備したもの、もしくは入力を更新せずにマネージドに作成されるものも使用可能です。設定ができたら、保存を押下します。 エージェントスペース画面に戻ると、脅威モデルについてもセットで有効化されていることが確認できます。 ペネトレーションテストの有効化 最後にペネトレーションテストの有効化ボタンを押下します。 先ほど設定したターゲットドメインを選択し、「次へ」ボタンを押下します。 ターゲットドメインが検証済みであることを確認し、「次へ」ボタンを押下します。 以下の設定項目について確認し、入力が完了したら保存を押下します。 VPC：VPC内でプライベートなエンドポイントを叩く場合など、Security AgentがVPC内のENIからターゲットにアクセスする際の設定 VPC、サブネット、セキュリティグループ CloudWatchログ：ログの出力先、任意 シークレット：テスト打鍵時にログインなどの認証情報を保存しておくために使用 Lambda関数：動的な認証情報生成用に独自デプロイしたものがあれば指定 Lambdaがない場合でも、テスト実行時のプロンプトでカバー可能かどうかは要検討 S3バケット：ペネトレーションテスト実行時にアプリケーションの構成などを学習するためのリソースとして使用可能 全項目が準備完了のステータスであることを確認して完了です。 開発者用コンソールの確認 エージェントスペース画面において、ウェブアプリケーションの項目から開発者用のコンソール（レビューやテストを実行する場所）を開くことができます。 管理者アクセスの場合は「管理者アクセス」ボタンを押下し、直接エージェントスペースに対応するコンソールに移動します。 エージェントウェブアプリのURLよりアクセスする場合は、紐付けたIAM Identity Centerユーザでログインしたのちに、そのユーザが使用可能なエージェントスペースの一覧が表示され、そこから指定のエージェントスペースに遷移する形となります。 以上で管理者側の設定は完了です。次に、実際にテストを実行します。 開発側の実行手順 開発者用のコンソール画面より、開発者側の操作（レビュー・テスト）を行います。 設計レビューの実行 ホーム画面から「設計レビューを作成する」を押下し、レビュー対象のファイルをアップロードして、「開始する」ボタンを押下します。 デザインレビューが進行中となります。 完了すると、コンソールからそのまま実施結果を確認することができます。 「レポートをダウンロード」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 コードレビューの実行 ホーム画面から「コードレビューを作成する」を押下し、以下の項目を設定して、「作成する」ボタンを押下します。 ソース：コードソースを選択。今回は先ほど設定したGitHubリポジトリを設定 サービスロール：管理者画面で設定したサービスロールを選択 CloudWatchロググループ：未入力で自動生成されます 自動コード修正：有効にするとレビュー結果に応じてPRを自動作成します 作成したコードレビューを押下します。 「レビューを開始する」ボタンを押下し、コードレビューを開始します。 ただし、プルダウンから差分コードレビューも選択可能です。2回目以降、頻繁に回す場合は差分レビューが推奨されると考えられます。（毎回フルリポジトリレビューを実行するとコストに響いていく想定） コンソールから結果を確認することができます。 「レポートを生成」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 脅威モデルの実行 ホーム画面から「脅威モデルを作成する」を押下し、以下の項目を設定して、「脅威モデルを作成する」ボタンを押下します。 リポジトリ：先ほど設定したコードソースを選択 機能仕様書：ドキュメントをアップロード サービスロール：管理者画面で作成したサービスロールを選択 CloudWatchロググループ：未入力で自動生成されます 設定完了後、「実行を開始する」ボタンを押下します。 実行結果についてはコンソールから取得できます。 「レポートを生成」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 ペネトレーションテストの実行 ホーム画面から「ペネトレーションテストを作成する」を押下し、以下の項目を設定して、「次へ」ボタンを押下します。 ターゲットや除外対象を調整することで、テストスコープを大まかに調整することができます。 ターゲットURL：検証済みのドメインをもとにURLを入力 リスクタイプを除外する：テストで検証しなくてもよい項目を選択し除外可能 範囲外のURL：テストでアクセスしてほしくないURLを入力（外部APIや決済処理、データの削除・更新などの副作用を伴うエンドポイント等） アクセス可能なURL：テスト中に攻撃対象ではないが、アクセスを許可するURLを入力 カスタムHTTPヘッダ：静的なヘッダのキーと値を設定（動的な設定がしたい場合は、以降の手順で対応） サービスロール CloudWatchロググループ VPCリソースの設定画面に遷移しますが、今回は設定項目がないため「次へ」ボタンを押してスキップします。 管理者画面で設定していた場合は、VPC、サブネット、セキュリティグループを設定可能です。 認証リソースの設定画面に遷移しますが、今回は設定項目がないため「次へ」ボタンを押してスキップします。 認証情報についてはシークレットまたは平文での静的情報が入力可能なほか、エージェントスペースのログインプロンプトに動的な認証方法に関する記載をすることで、動的な認証にも対応できます。 実際に、動的にトークンを生成してカスタムヘッダに載せる必要があるアプリで動作を確認できました。 その他の設定画面において、以下を設定し、「ペネトレーションテストモデルを作成する」ボタンを押下します。 リソース：コードソースなどを設定 自動コード修正：有効化するとペネトレーションテストの結果に応じてPRを自動作成 検出結果のパーソナライゼーション（ オンオフでの差分未確認 ） リソースを可能な限りクリーンアップ（ オンオフでの差分未確認 ） 作成後、「実行を開始する」ボタンを押します。 実行結果についてはコンソールから取得できます。 テストの取得結果数が少ないのは、実行中に裏側で呼び出しているBedrockの存在に気づき、コスト懸念のため途中で中止したためです。 レポートの確認 デザインレビュー デザインレビューについては、「レポートをダウンロード」からCSV形式でレポートを取得できます。 デザインレビューは手動でファイルを読み込ませる形式で自動修正等もないため、このCSVを手元のAIエージェントに読み込ませて修正することを想定しています。 脅威モデル 脅威モデルの場合は、「レポートを生成」ボタンを押下すると、レポートをPDF形式で取得することができます。 体裁（抜粋） 構成 Introduction 脅威モデルの対象、実施日、検出された脅威件数、重大度の内訳 System Overview 対象システムの目的、機能、アーキテクチャ、主要コンポーネントの説明 Configuration 脅威モデルに使用したスコープ文書、連携リポジトリ、S3ソース、ドキュメントなどの設定情報 Threats 実際に検出された脅威シナリオの一覧 Detailed Threats 各脅威シナリオに対する攻撃者、攻撃が成立するための前提条件、具体的な攻撃方法、攻撃成功時の影響、脅威の根拠、脅威の判断に紐づく構成箇所 System Overview章では設計書やコードから、アプリの構成に関する洞察がかなり細かく記載されており、セキュリティ上のリスクを多角的に把握する上で非常に有用であると感じます。 コードレビュー・ペネトレーションテスト 同様に、コードレビューやペネトレーションテストの場合は、「レポートを生成」ボタンを押下すると、レポートをPDF形式で取得することができます。 体裁（抜粋） 構成 Report Filters Applied このレポートに含めるリスクレベル、信頼度、ステータスなどの抽出条件 Executive Summary テスト対象、実施日、検出された脆弱性件数、重大度の内訳 Scope ペネトレーションテスト：対象URL、対象外URL、利用した認証情報 コードレビュー：対象リポジトリ、S3バケット Methodology AWS Security Agent がどのような流れ・観点でテストを実施したかの説明 ペネトレーションテストの場合は、表形式でXSS、SQL Injection、SSRF、Path Traversalなど、実際に実施されたテスト項目の一覧を記載 Findings 実際に検出されたセキュリティ指摘の一覧 Detailed Findings 各セキュリティ指摘に対する、概要、再現手順、 CVSS（Common Vulnerability Scoring System）評価 の根拠、推奨修正方針、修正対応PR ペネトレーションテストの結果におけるMethodology章では、例えば私のサービスではバックエンドにDynamoDBやSQLを使用している点から、それらの要素を突くような攻撃を実施した旨が記載されていました。これは、学習リソースとしてGitHubリポジトリを与えたために、IaCで管理しているリソースやアプリケーションロジックを総合して攻撃方法を検討していることが確認できました。 まさに、 AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始 で紹介されていたような、 アプリケーションコンテキストを追加して精度と検出の深度を向上 させるという面が見られたのではないかと感じます。 また、今回はコードレビューとペネトレーションテストの際にリポジトリへの修正PRを許可していることから、自動でPRを立てていました。 実施理由から変更内容、サマリまでが簡潔にまとめられていることがわかります。コードの質に関しては、今回はそこまで複雑なアプリではないこともあり、特に気になる点はなかったと感じますが、ぜひ皆さんの使用時に確認していただければと思います。 CI/CDへの組み込み AWS Security Agent は、CodePipeline 等の CI/CD や定期的な管理タスクとして実行させることが可能で、 AWS CLI / API 経由でジョブを起動できます。 今回は、GitHub Actions での使用イメージを記載します。以下は、デザインレビュー・コードレビュー・ペネトレーションテストを、大まかに GitHub Actions に組み込んだ場合のイメージです。 タイミング 実行するもの 性質 develop マージ リポジトリ全体のコードレビュー 軽量・低コスト・高頻度 main マージ stg へ反映（テストは伴わないデプロイトリガー） — stg デプロイ完了後 軽量ペンテスト（対象を絞る） 中コスト・中頻度 リリース時 / 定期 フルスコープのペンテスト 高コスト・低頻度 設計ドキュメント更新時 デザインレビュー 随時 CLIコマンドの基本構造 AWS Security Agent の各機能は、以下の流れで実行します。AWS Security Agent 関連リソースはあらかじめコンソールまたは create コマンドで定義しておき、CI/CD からは名前を基に list-* コマンドでIDを取得し start-*-job で起動するのが基本です。 機能 起動コマンド 主な必須引数 コードレビュー aws securityagent start-code-review-job --agent-space-id / --code-review-id ペネトレーションテスト aws securityagent start-pentest-job --agent-space-id / --pentest-id デザインレビュー（脅威モデリング） aws securityagent start-threat-model-job --agent-space-id / --threat-model-id 例えばペネトレーションテストの起動は、コンソールから設定した場合は名前を元に以下のようになります。Agent Space やペンテスト定義の実IDは list-* 系コマンドで name / title を条件に取得し、 start-pentest-job に渡します。 $ AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text \ --region ap-northeast-1) $ PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text \ --region ap-northeast-1) $ aws securityagent start-pentest-job \ --agent-space-id "$AGENT_SPACE_ID" \ --pentest-id "$PENTEST_ID" \ --region ap-northeast-1 start-pentest-job は pentestJobId と status （ IN_PROGRESS / COMPLETED / FAILED など）を返します。短時間で完了するコードレビューやデザインレビューは、この status をポーリングして完了を待つ構成にできます。一方、数時間〜数十時間かかるペネトレーションテストは、GitHub Actions の実行時間制限（後述）の都合から、起動のみ行う非同期キック構成とします。 以下では、各フェーズで実行する workflow の YAML ファイル例を示します。なお、いずれの例も Agent Space 名や各リソース名（ title ）、AWS 認証情報（OIDC ロール等）を GitHub の Secrets / Variables に登録している前提です。リソース ID は workflow 内で list-* から動的に解決するため、ID 自体は Variables に持ちません（コンソール側で再作成された場合の追従が楽になります）。 共通： AWS 認証（OIDC） 各 workflow で共通して使う、OIDC による AWS 認証部分の例です。長期のアクセスキーを GitHub に保存せず、フェデレーションでロールを引き受ける構成にしています。 permissions : id-token : write contents : read steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ap-northeast-1 develop マージ時： コードレビュー develop への push（マージ）をトリガーに、リポジトリ全体のコードレビューを起動します。高頻度で回すため、軽量・低コストなレビューを想定しています。 # .github/workflows/code-review.yml name : security-agent-code-review on : push : branches : [ develop ] permissions : id-token : write contents : read jobs : code-review : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} CODE_REVIEW_NAME : ${{ vars.CODE_REVIEW_NAME }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) CODE_REVIEW_ID=$(aws securityagent list-code-reviews \ --agent-space-id "$AGENT_SPACE_ID" \ --query "codeReviewSummaries[?title=='$CODE_REVIEW_NAME'].codeReviewId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$CODE_REVIEW_ID" ] || [ "$CODE_REVIEW_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID CODE_REVIEW_ID=$CODE_REVIEW_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "code_review_id=$CODE_REVIEW_ID" >> "$GITHUB_OUTPUT" - name : Start code review job id : start run : | JOB_ID=$(aws securityagent start-code-review-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --code-review-id "${{ steps.resolve.outputs.code_review_id }}" \ --query 'codeReviewJobId' --output text) echo "job_id=$JOB_ID" >> "$GITHUB_OUTPUT" echo "Started code review job: $JOB_ID" - name : Wait for completion run : | JOB_ID="${{ steps.start.outputs.job_id }} " AGENT_SPACE_ID=" ${{ steps.resolve.outputs.agent_space_id }} " for i in $(seq 1 60); do STATUS=$(aws securityagent batch-get-code-review-jobs \ --agent-space-id "$AGENT_SPACE_ID" \ --code-review-job-ids "$JOB_ID" \ --query 'codeReviewJobs[0].status' --output text) echo "status=$STATUS" case "$STATUS" in COMPLETED) echo "Code review completed" ; exit 0 ;; FAILED|STOPPED) echo "Code review did not succeed: $STATUS" ; exit 1 ;; esac sleep 30 done echo "Timed out waiting for code review" ; exit 1 stg デプロイ完了後： 軽量ペンテスト（DAST・対象を絞る） main マージ後の stg デプロイ完了を受けて、対象を絞った軽量なペネトレーションテストを実行します。 ペネトレーションテストは数時間〜数十時間かかる場合があり、GitHub ホストランナーの 1 ジョブ最大 6 時間という実行時間制限を超える恐れがあります。そのため、ここでは 起動のみを行い、完了は待たない（非同期キック） 構成とします。テストの進捗・結果は、コンソールや EventBridge 通知などジョブの外で確認する想定です。 # .github/workflows/pentest-light.yml name : security-agent-pentest-light on : workflow_run : workflows : [ "deploy-stg" ] # stg デプロイ workflow 名 types : [ completed ] permissions : id-token : write contents : read jobs : pentest-light : # デプロイが成功したときだけ実行 if : ${{ github.event.workflow_run.conclusion == 'success' }} runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} PENTEST_NAME : ${{ vars.PENTEST_NAME_LIGHT }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$PENTEST_ID" ] || [ "$PENTEST_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID PENTEST_ID=$PENTEST_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "pentest_id=$PENTEST_ID" >> "$GITHUB_OUTPUT" - name : Start light pentest job (fire-and-forget) run : | JOB_ID=$(aws securityagent start-pentest-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --pentest-id "${{ steps.resolve.outputs.pentest_id }}" \ --query 'pentestJobId' --output text) echo "Started light pentest job: $JOB_ID" echo "進捗・結果はコンソールまたは EventBridge 通知で確認してください。" リリース時 / 定期： フルスコープのペネトレーションテスト リリースタグの push、または定期実行でフルスコープのペネトレーションテストを起動します。高コスト・低頻度の枠です。 ペネトレーションテストは数時間〜数十時間かかる場合があり、GitHub ホストランナーの 1 ジョブ最大 6 時間という実行時間制限を超える恐れがあります。そのため、ここでは 起動のみを行い、完了は待たない（非同期キック） 構成とします。テストの進捗・結果は、コンソールや EventBridge 通知などジョブの外で確認する想定です。 # .github/workflows/pentest-full.yml name : security-agent-pentest-full on : push : tags : [ "v*" ] # リリースタグ schedule : - cron : "0 18 * * 0" # 毎週日曜 18:00 UTC（=月曜 3:00 JST）に定期実行 permissions : id-token : write contents : read jobs : pentest-full : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} PENTEST_NAME : ${{ vars.PENTEST_NAME_FULL }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$PENTEST_ID" ] || [ "$PENTEST_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID PENTEST_ID=$PENTEST_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "pentest_id=$PENTEST_ID" >> "$GITHUB_OUTPUT" - name : Start full pentest job (fire-and-forget) run : | JOB_ID=$(aws securityagent start-pentest-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --pentest-id "${{ steps.resolve.outputs.pentest_id }}" \ --query 'pentestJobId' --output text) echo "Started full pentest job: $JOB_ID" echo "長時間ジョブのため、結果はコンソールまたは EventBridge 通知で確認してください。" 設計ドキュメント更新時： デザインレビュー（脅威モデリング） 設計ドキュメント（ docs/design/ 配下など）の更新をトリガーに、デザインレビュー（脅威モデリング）を起動します。STRIDE 形式での脅威モデル生成を想定しています。 # .github/workflows/design-review.yml name : security-agent-design-review on : push : paths : - "docs/design/**" # 設計ドキュメントの更新時のみ permissions : id-token : write contents : read jobs : design-review : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} THREAT_MODEL_NAME : ${{ vars.THREAT_MODEL_NAME }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) THREAT_MODEL_ID=$(aws securityagent list-threat-models \ --agent-space-id "$AGENT_SPACE_ID" \ --query "threatModelSummaries[?title=='$THREAT_MODEL_NAME'].threatModelId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$THREAT_MODEL_ID" ] || [ "$THREAT_MODEL_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID THREAT_MODEL_ID=$THREAT_MODEL_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "threat_model_id=$THREAT_MODEL_ID" >> "$GITHUB_OUTPUT" - name : Start threat model job id : start run : | JOB_ID=$(aws securityagent start-threat-model-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --threat-model-id "${{ steps.resolve.outputs.threat_model_id }}" \ --query 'threatModelJobId' --output text) echo "job_id=$JOB_ID" >> "$GITHUB_OUTPUT" - name : Wait for completion run : | JOB_ID="${{ steps.start.outputs.job_id }} " AGENT_SPACE_ID=" ${{ steps.resolve.outputs.agent_space_id }} " for i in $(seq 1 60); do STATUS=$(aws securityagent batch-get-threat-model-jobs \ --agent-space-id "$AGENT_SPACE_ID" \ --threat-model-job-ids "$JOB_ID" \ --query 'threatModelJobs[0].status' --output text) echo "status=$STATUS" case "$STATUS" in COMPLETED) exit 0 ;; FAILED|STOPPED) echo "Threat model did not succeed: $STATUS" ; exit 1 ;; esac sleep 30 done echo "Timed out" ; exit 1 まとめ 最近よく話題に挙がるDevOpsにセキュリティを加えた概念、 DevSecOps に沿ったモダンなサービスだと感じました。 今回のAWS Security Agentでは、 コンソール操作だけでなくAPI経由でCICDに取り込める点 、 レビューから修正までをAIで一括管理できる点 、さらに コードレビューやペネトレーションテストにおいて差分レビューやターゲットURL・除外項目の設定などでスコープを調整できる点 から、このDevSecOpsのコンセプトを強く反映しています。 また、単なる効率化にとどまらず、ドキュメントとして人向けに残す成果物まで整備されている点も充実しています。 一方で、懸念点としては以下の3点が挙げられます。 コスト ：プレビュー中の機能もありますが、実際にCI/CDへ組み込んだ際の料金イメージが読みにくい点。エージェントを個別に構築する場合と比較した、運用コスト・性能とのバランス。 秘匿ドキュメントの管理 ：社内の機密情報や個人情報を含むドキュメントをクラウド上にアップロードすることになるため、要件によっては慎重な判断が必要。 データは既定でAWSマネージドキーにより暗号化され、任意でカスタマーマネージドキー（CMK）を指定して自社で鍵を管理することも可能であり、保護の仕組みは用意されている。そのため、最終的には自社のセキュリティ要件に照らして判断することになる想定。 レビューやテストの性能 ：現在の検出性能や今後の伸びしろについて、セキュリティエンジニアの視点でのご意見をぜひお聞きしたいと感じています。 おわりに 本記事では、AWS Security Agentの概要を紹介しました。今後も、機能の追加や検出性能そのもののアップグレードが期待されます。 ただし、偽陽性が多いのではないかという声も聞いたため、検出性能については別途、評価・比較してみたいと考えています。 ご精読いただき、ありがとうございました。 余談になりますが、先輩と話した際に挙がった、「ペネトレーションテストを主軸に開発を進める中で、アプリケーションのコンテキストを理解させるために、結局は設計レビュー・コードレビュー・脅威モデリングが必要になり、機能として統合されていったのではないか」という見方には、かなり納得できました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sakae.katsuto レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）