こんにちは。エンタープライズ第一本部 戦略ソリューション 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 で執筆されました ）

金融IT本部の河岸です。 先日、クロスイノベーション本部の大岡叡さんが主催する「25卒合同AWS勉強会 #3」に参加してきました。本ブログでは、その様子をお届けします。 去年12月にスタートしたAWS勉強会も今回で3回目。今回は参加企業が7社、参加者は34名となり、コミュニティは回を重ねるごとに拡大しています。AWSを学ぶ同期たちが会社の垣根を越えて集まり、最新技術や実案件の知見を共有する場へと成長してきました。 (ぜひ 第1回 と 第2回 の記事もあわせてご覧ください！) 開催背景 イベント概要 イベント内容 振り返り 気づき まとめ 開催背景 第2回勉強会後に、各社代表(NECソリューションイノベータ株式会社の上田賢哉様、キャップジェミニ株式会社の遊佐康平様、株式会社OptiMaxの髙橋光様)と振り返りを行いました。(今回より私も運営側で参加させていただくことになりました) コミュニティのさらなる活性化と発展に向けた施策として、「参加企業の拡大」と「気軽に質問できる環境づくり」といった部分が挙げられ、各社代表が中心となって、社外の方々に向けた呼びかけを行っていただきました。 その結果、合計7社の皆様にご参加いただくことができました！ イベント概要 開催日時：2026/6/26(金) 開催場所：電通総研 品川本社 開催形態：ハイブリッド(対面+オンライン) 参加者：34名 参加企業： NECソリューションイノベータ株式会社、キャップジェミニ株式会社、 株式会社OptiMax 、株式会社マイナビ、弊社、ほか2社(順不同) イベント内容 各社から1名ずつ(計6名)登壇し、AWSに関係するテーマで10分間+質疑5分ずつ発表しました。当日のアジェンダは以下のとおりです。 時間 内容 所属 発表者 (敬称略) 発表テーマ 19:00 開会 - - - 19:05 発表 電通総研 藤代 彩希 実案件から学ぶVPC接続経路の選択 19:20 発表 非公開 非公開 EventBridgeのアルゴリズム 19:35 発表 OptiMax 浦田 海翔 インデックスとOpenSearch Serverless 19:50 休憩 - - - 20:05 発表 キャップジェミニ 齊藤 樹 AWSエンジニアが知っておくべき量子コンピュータ対策〜量子技術によるクラウドセキュリティの未来〜 20:20 発表 マイナビ 嶺山 陽和 AWS MCP を用いたAI駆動インフラ構築の実践 20:35 発表 NECソリューションイノベータ 城前 りりか Durable functionsで実現するステートフルワークフロー 20:50 閉会 - - - 振り返り 各発表の内容を簡単にご紹介できればと思います。 1. 実案件から学ぶVPC接続経路の選択 VPC接続経路の選択について、実際の案件で得られた知見をもとに解説していただきました。改めてPrivateLinkとTransit Gatewayのメリット・デメリットや使い分けを整理する良い機会となりました。 2.EventBridgeのアルゴリズム AWSが内部実装を公開していないEventBridgeに対し、「どのようなアルゴリズムで大量イベントを処理しているのか」を仮説ベースで掘り下げた発表でした。普段はサービス利用者として触れるだけのAWSを、内部実装の視点から考察する内容で、会場からも多くの質問が寄せられていました。 3.インデックスとOpenSearch Serverless RAGを用いた検索精度向上のための手法の解説とOpenSearch ServerlessとRAG関連サービスの組み合わせをユースケースごとに紹介していただき、AIアプリ開発の参考になる知見が盛りだくさんでした。 4. AWSエンジニアが知っておくべき量子コンピュータ対策〜量子技術によるクラウドセキュリティの未来〜 量子コンピュータの発展により、従来の暗号化技術では対応できなくなる可能性があるというお話でした。自分が設定する暗号化方式一つ取っても、場合によっては量子コンピュータの登場によって解読されてしまうリスクがあるということを改めて認識させられ、セキュリティに対する意識を向上させることができました。 5.AWS MCP を用いたAI駆動インフラ構築の実践 AWSが提供するMCPの基礎的な解説とアーキテクチャの実現例を紹介していただきました。LLMのみで完結させるアプローチと比較して、LLMからMCPを呼び出してWebフェッチする仕組みとの違いなどを知ることができました。 6.Durable functionsで実現するステートフルワークフロー Lambdaを使ってステートフルに長時間実行を実現するための手段としてDurable Functionsを活用する方法について紹介していただきました。AIワークフローや複雑な非同期処理など、様々なユースケースへの応用可能性を考えることができ、非常に学びの多いセッションとなりました。 気づき 今回で3回目の開催となり、会社間の垣根を越えた交流も定着して、質問やディスカッションが一段と活発になりました。社外の同期とAWSを通じて語り合えるコミュニティが、着実に形になりつつあると実感しています。同期だからこそ些細な疑問も気兼ねなく投げ合うことができ、互いに刺激を受けることで、さらなる学習のモチベーションアップにつながることも改めて感じました。 また勉強会後の懇親会でも、「モチベーションが上がった」「これまでAWSに触れたことはなかったが、これを機に勉強したくなった」などといった声をいただき、とても有意義な時間にできたことを嬉しく思います。 まとめ 今回は「25卒合同AWS勉強会 #3」の様子をお伝えしました。次回は9月ごろに第4回を開催する予定です。 今後も引き続き、25卒同期主体の閉じた勉強会ではありつつも、より多くの企業・参加者を巻き込みながら、より良い時間にできるように引き続き改善を重ねていきたいと思います。 ご参加いただいた皆様、誠にありがとうございました！次回もご参加お待ちしております！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kawagishi.ibuki レビュー： @kinjo.ryuki （ Shodo で執筆されました ）

はじめに こんにちは、クロスイノベーション本部の藤川（善）です。 最近、あるWebサイトで 「自己署名証明書」 の使用が検出され、調査した内容を記事にします。 結論としては不備ではなくて、IPアドレス指定で共有ホスティング環境にアクセスした際に表示される自己署名証明書は、 セキュリティ目的で意図的に設定されたダミー証明書 でした。普段あまり目にしないであろう .invalidトップレベルドメイン（TLD） についても本記事内で触れます。 背景 サイバーセキュリティの中にASM（Attack Surface Management）という分野があります。インターネットに公開しているWebサイトを代表とする資産は、情報窃取やコンテンツ改ざんなどを狙う攻撃者からもアクセスされてしまいますが、不正侵入経路となりうる部分を把握・管理する活動です。イメージしやすい内容としては、脆弱性がないかツールを使用して定期的にスキャンし、もし脆弱性を検出した場合は優先度などを勘案して対策を打ちます。 代表的なところでは、以下のような脆弱性を検査しています。 Webアプリケーションの脆弱性（XSSなど） 不要なポートの公開（FTPやPOP3） 脆弱なミドルウェアの利用 証明書設定の不備（有効期限切れなど） 上記の「証明書設定の不備」の一環で、あるWebサイトで「自己署名証明書を使用している」という事象が検出されたのが発端でした。 しかし当該Webサイトは、正規の認証局（CA）から発行されたサーバ証明書を使用しているはずで、 自己署名証明書（Self-Signed Certificate） には心当たりがありませんでした。 以前、社内メンバーのみが利用するサイトでActiveDirectoryの証明書サービスで発行したプライベートCA署名証明書を組み込んだことがあります。用途次第では正規CAが発行した証明書でなくても問題ありませんが、今回対象となっているWebサイトは社外向けですので看過しづらいです。 初期調査 ドメイン指定でアクセスした場合は問題ないという情報もありました。まずアクセス方法による違いをWebブラウザで確認したところ、以下のように挙動が異なることがわかりました。（ドメイン名・IPアドレスは架空のものです） ドメイン指定 https://example.com/ → ✅ 問題なし（正常な証明書）Web画面も正常表示 IPアドレス指定 https://203.0.113.1:443/ → ❌ 問題あり（自己署名証明書）エラー表示「この接続ではプライバシーが保護されません」 この結果から、「サーバ全体が誤設定されているわけではない」ことが見えてきました。利用者は通常はドメイン指定でアクセスしますから、正常な証明書を取得できていると考えられます。 IPアドレスを指定してアクセスすると問題が起きます。 さてインフラ構成を確認すると、当該Webサイトは 共有ホスティング環境 を使用していることが判明しました。 共有ホスティングとSNI 共有ホスティングでは、1つのIPアドレスに複数のドメインを対応させて運用します。 動作しているドメインごとにサーバ証明書は異なるものが使用されます。HTTPSでのアクセスを受けると、どの証明書を返すかを識別する必要があり、 SNI（Server Name Indication） という仕組みを用いています。SNIでは、TLS通信の初期段階でクライアントから Client Hello メッセージを送り、その中でどのドメインに接続するかを伝えます。 SNIあり / ドメイン指定でのアクセス ドメイン指定でアクセスした場合は、SNIで接続先ドメインを識別して、対応するサーバ証明書を返します。 SNIなし / IPアドレス指定でのアクセス IPアドレス指定でアクセスした場合には、SNIによりドメインを識別できないため、共有ホスティングを行っているサーバはデフォルトの証明書を返します。デフォルト証明書とは言っても、異常なアクセスをされている扱いをしており、内容としてはエラーを示すものとなります。 opensslコマンドによるサーバ証明書の確認方法 実際のサーバ証明書の内容を確認してみました。Webブラウザでも概要は参照できますが、 openssl コマンドで詳細に確認できます。今回は手近なAWSのCloudShellで以下のように実行しました。 ドメイン指定 openssl s_client -connect example.com:443 -servername example.com < /dev/null |\ openssl x509 -noout -text 細かな説明は省きますが s_client コマンドにより、実際にサーバに接続します。 -servername オプションで接続するドメイン名を提示しています（なお現在一般的なバージョンでは、 -servername オプションを省略すると -connect のドメイン名がSNIに使用されるため、同じ結果になります）。 後半の x509 コマンドでは証明書のバイナリからテキスト形式でドメイン一覧（SAN；後述）を取り出しています。 IPアドレス指定 openssl s_client -connect 203.0.113.1:443 < /dev/null |\ openssl x509 -noout -text こちらでは -servername オプションを指定しておらず、加えて -connect もIPアドレス指定としているため、接続するドメイン名が提示されません。 出力結果のうち、今回の調査に関わる主要確認ポイントは下表のとおりです。 項目 意味 Subject (CN) 証明書の対象 Issuer (CN) 発行した認証局 SAN（Subject Alternative Name） 有効なドメイン一覧 サーバ証明書の内容比較 出力結果から主要確認ポイントを抜き出すと以下のようになりました。 ドメイン指定 Subject: CN=example.com Issuer=（正規CA） X509v3 Subject Alternative Name: DNS:example.com → ✅ 正常 正規の認証局が発行した証明書、SAN（Subject Alternative Name）の中にドメインexample.comが記載されている IPアドレス指定 Subject: CN=reject.invalid, O=Reject vhost (self-signed) Issuer: CN=reject.invalid, O=Reject vhost (self-signed) X509v3 Subject Alternative Name: （表示されない；SANフィールド自体が証明書に含まれていない） → ❌ ドメイン不一致 self-signed とあるので自己署名証明書である。SANがなくIssuerは reject.invalid reject.invalidの正体と自己署名証明書 自己署名証明書のIssuerに表示されている reject.invalid とは何でしょうか。 .invalid：RFC 6761（元はRFC 2606）で予約されている、存在しないトップレベルドメイン。.invalid自体とサブドメインは、実在のドメイン名と衝突する心配がなく、無効であることが明確 reject：拒否 つまりこの証明書は 「正しいドメイン名でアクセスしていないため拒否する」 ことを示すためのダミー証明書 です。 DNSレジストラは.invalid TLDに含まれるドメインを登録してはいけない決まりとなっています。CAに証明書の発行を依頼しても拒否されるでしょうし、ダミー証明書として共有ホスティング環境が生成した自己署名証明書を使うのは自然だと受け取りました。 余談ですが、 example.com や example.net もRFC 6761に記載されています。 デフォルト証明書の考え方 なぜ正しいドメイン名を伝達していない場合にIssuer: reject.invalid のデフォルト証明書を返したのでしょうか。いずれかのドメインの証明書（当記事の例ではexample.com）を返すこともできそうに思えます。 これについては、デフォルト証明書として正規の証明書を返してしまうと、IPアドレス直接指定でも証明書が取得可能となり、証明書情報（SANなど）が外部に露出しやすくなることが懸念されます。結果として攻撃者によるスキャンや調査を誘引することになります。 一方で reject.invalid の証明書を返すことは、SNI前提の設計原則に沿っていますし、不正アクセスを明示的に拒否することで不要な情報露出を防ぐ効果があります。一見、設定ミスのようでもありますが、「正しいホスト名でアクセスしてください」というサーバからの明確な意思表示とも言え、意図的な設計だと考えられます。 なお、この挙動によって攻撃そのものが完全に防げるわけではありません。IPアドレスに対応するドメイン名は各種手法で特定可能であるため、意図的な攻撃者はドメイン名を指定してアクセスすることができます。あくまで軽減策です。 まとめ 今回の調査では以下のポイントが判明しました。 共有ホスティング環境ではSNI（Server Name Indication）により、クライアントが提示したドメインに対応するサーバ証明書が返される IPアドレス指定でアクセスした際は、ドメイン指定がないため拒否を示すデフォルト証明書（自己署名証明書）が返された デフォルト証明書のIssuer: reject.invalid は誤設定ではなく、防御的設計と考えられる 不具合かのように見える挙動でも、実際にはセキュリティ設計上の意図であるケースがあり、背景を理解して判断することが重要だと考えさせられた調査結果でした。心当たりのない自己署名証明書について調査する際に参考にしてください。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @jiffy レビュー： @nagamatsu.yuji （ Shodo で執筆されました ）

こんにちは。クロスイノベーション本部 AIデータテクノロジーユニット AIトランスフォーメーションセンターの青木 尚人です。 本記事では、SOPS を利用してチーム開発の環境変数管理を標準化する方法を紹介します。 はじめに チーム開発で .env を使っていると、次のような運用になりがちです。 .env の実際の値を Slack や Teams で共有する 新規メンバーが入るたびに、誰かが .env を手作業で渡す .env.example はあるが、実際の値とはずれている どの値が最新なのかわからない 秘密情報とそうでない値が混ざっている .env を誤って Git にコミットしてしまう そこで今回は、 SOPS + Azure Key Vault + mise を使って、暗号化された .env を Git 管理できるようにします。 この記事で紹介するのは、次のような手順での環境変数の管理方法です。 SOPS で .env 形式のファイルを暗号化する Azure Key Vault の Key を SOPS の暗号化・復号に使う mise で sops と azure-cli を導入する mise task で .env の復号・生成コマンドを標準化する この記事の前半では、まず SOPS を利用して暗号化された環境変数を作成します。 その後、mise task を使って .env の生成手順を標準化します。 本記事で紹介するプロジェクトで想定している最小の構成は以下です。 Existing Git Repository ├── .env.sops.env # SOPSで暗号化された.env。Git管理する ├── .env # 復号して生成する.env。Git管理しない ├── .sops.yaml # SOPSの暗号化設定。Git管理する └── mise.toml # ツールとタスク定義。Git管理する Azure Key Vault └── Key Vault Key # SOPSの暗号化・復号に使う鍵 SOPS とは SOPS は、YAML、JSON、ENV、INI などのファイルを暗号化して管理するためのツールです。 公式ドキュメント： https://getsops.io/docs/ GitHub リポジトリ： https://github.com/getsops/sops 一般的な暗号化ツールと違い、ファイル全体を単純にバイナリ化するのではなく、設定ファイルとして扱いやすい形で暗号化できます。 例えば .env 形式のファイルであれば、暗号化後もキー名は読める状態にしつつ、値だけを暗号化できます。 似た選択肢としては、Azure Key Vault Secret に環境変数を1つずつ保存する方法、 .env.example で項目だけ共有する方法、 .env ファイルの暗号化に特化したツールとして dotenvx もあります。 dotenvx は、既存の .env 運用に近い形で暗号化された .env ファイルを扱えるため、 .env を中心にシンプルに管理したい場合は有力な選択肢です。 一方、今回の構成では Azure Key Vault の Key を使って復号権限を Azure 側で制御したかったため、SOPS を採用しています。 SOPS は .env だけでなく YAML、JSON、INI など複数の設定ファイル形式を扱えるため、環境変数以外の設定ファイル管理にも広げやすい点もメリットです。 暗号化前の .env が次のような内容だったとします。 DATABASE_URL=postgresql://demo_user:demo_password@localhost:5432/demo_db API_TOKEN=dummy-api-token JWT_SECRET=dummy-jwt-secret SOPS で暗号化すると、次のようなファイルになります。 DATABASE_URL=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] API_TOKEN=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] JWT_SECRET=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] この状態なら、暗号化された .env ファイルを Git 管理できます。 値は暗号化されているため、リポジトリに置いても平文の secret は見えません。 Azure Key Vault は何に使うのか 今回、Azure Key Vault は、環境変数そのものの保存先ではなく、SOPS がデータキーを保護するための Key Vault Key の管理基盤として使います。 Azure Key Vault では、主に次の3種類のオブジェクトを管理できます。 Key Secret Certificate このうち、今回使うのは Secret ではなく Key です。 環境変数を Azure Key Vault Secret に1つずつ保存する構成ではありません。 SOPS が暗号化・復号に使う鍵を、Azure Key Vault Key として管理します。 Azure Key Vault └── Key └── SOPSが.env.sops.envを暗号化・復号するために使う SOPS は、ファイル本体の値を暗号化し、その暗号化・復号に必要な情報をファイル内に保持します。 ただし、その復号には Azure Key Vault Key へのアクセス権が必要です。 そのため、次のような管理ができます。 Git には暗号化済みの .env.sops.env を配置する 復号できる人は Azure Key Vault の権限で制御する チャットで .env の平文を共有しない メンバー追加・削除時は Azure 側の権限を見直す ここが、この構成の重要なポイントです。 mise とは mise は、プロジェクトで使う CLI ツールのバージョン管理や、タスク定義をまとめて扱えるツールです。 SOPS と Azure CLI を各メンバーが個別にインストールしても、この構成は実現できます。 ただし、それだと次の問題が残ります。 SOPS がインストールされていない Azure CLI がインストールされていない メンバーごとにバージョンが異なる .env を生成するコマンドを毎回説明する必要がある mise を使うと、プロジェクトに必要な CLI ツールとタスクを mise.toml にまとめられます。 [tools] sops = "3.12.2" azure-cli = "2.84.0" これをプロジェクトに置いておけば、メンバーは次のコマンドで必要なツールをそろえられます。 mise install さらに、 .env を生成する処理も mise task にできます。 mise run env:render つまり mise を使う理由は、単にツールを入れたいからではありません。 チーム全員が同じコマンドで、同じ手順を実行できるようにするため です。 ここからは、mise のインストール手順から、Azure Key Vault と SOPS を使った環境変数の管理手順までを順に紹介します。 mise をインストールする macOS では Homebrew でインストールできます。 brew install mise zsh を使っている場合は、シェルに mise を有効化する設定を追加します。 echo 'eval "$(mise activate zsh)"' >> ~/.zshrc source ~/.zshrc インストールできたか確認します。 mise --version macOS 以外のインストール方法は、公式ドキュメントを参照してください。 https://mise.jdx.dev/getting-started.html mise.toml に sops と azure-cli を追加する 既存プロジェクトのルートに mise.toml を用意します。 すでに mise.toml がある場合は、既存の [tools] に追記してください。 [tools] sops = "3.12.2" azure-cli = "2.84.0" コマンドで追加する場合は、以下のようにします。 mise use sops@3.12.2 mise use azure-cli@2.84.0 その後、ツールをインストールします。 mise install 確認します。 sops --version az version Azure にログインする SOPS が Azure Key Vault を使って復号するには、ローカル端末が Azure に認証済みである必要があります。 まず Azure にログインします。 az login 現在のサブスクリプションを確認します。 az account show -o table 必要であれば、利用するサブスクリプションに切り替えます。 az account set --subscription "<subscription-id-or-name>" Azure Key Vault と Key を作成する すでにチームで利用している Key Vault がある場合は、既存の Key Vault に SOPS 用の Key を追加しても構いません。 Key Vault の作成 Azure Portal から操作する場合は以下のようになります。 トップ画面からキーコンテナーを選択します。 作成ボタンを押下して、キーコンテナーを作成します。 基本タブでリソースグループとリージョンを選択します。 アクセス制御タブでは「Azureロールベースのアクセス制御(RBAC)」を選択してください。 ネットワークタブでは必要に応じてアクセス制御を設定します。 ここではデフォルトの「すべてのネットワークからのアクセスを許可する」を選択します。 ※実運用では要件に合わせて制限してください。特に本番 secret に関わる Key Vault では、ネットワーク制限を含めた設計が必要です。 最後に確認タブで設定を確認し、作成ボタンを押下してキーコンテナーを作成します。 Key Vault のアクセス制御で権限を付与する 次に、Key Vault の Key を使えるように、アクセス制御で権限を付与します。 アクセス制御（IAM）タブを開き、ロールの割り当てを追加します。 Key Vault の Key を作成・編集する管理者には「キー コンテナー暗号化責任者」を割り当てます。 一方で、一般的な開発メンバーが環境変数の暗号化・復号に利用するだけであれば、「キー コンテナー暗号化ユーザー」を割り当てるのが適切です。 ここでは、Key を作成するために「キー コンテナー暗号化責任者」のロールを自身に割り当てます。 SOPS 用の Key の作成 [オブジェクト > キー] のタブから「+ 生成/インポート」を押下します。 名前や RSA キーサイズを選択して、環境変数を暗号化する SOPS 用の Key を作成します。 作成した Key の ID を取得します。 出力例は以下のとおりです。 https://kv-sops-xxxx.vault.azure.net/keys/sops-env-key/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx この Key ID を SOPS の設定で使います。 .sops.yaml を追加する プロジェクトルートに .sops.yaml を追加します。 creation_rules : - path_regex : \.env\.sops\.env$ azure_keyvault : - https://kv-sops-xxxx.vault.azure.net/keys/sops-env-key/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx この設定により、 .env.sops.env という名前のファイルを SOPS で作成するときに、Azure Key Vault の Key が使われます。 暗号化前の .env を用意する ここでは、既存の .env から secret を含む値を暗号化する想定で進めます。 記事用の例ではダミー値を使います。 .env.plain という名前で、次のような内容を用意します。 DATABASE_URL=postgresql://demo_user:demo_password@localhost:5432/demo_db API_TOKEN=dummy-api-token JWT_SECRET=dummy-jwt-secret SOPS で .env を暗号化する .env.plain を SOPS で暗号化し、 .env.sops.env を作成します。 sops encrypt \ --filename-override .env.sops.env \ --input-type dotenv \ --output-type dotenv \ .env.plain > .env.sops.env 暗号化後のファイルを確認します。 cat .env.sops.env 次のように値が ENC[...] 形式になっていれば成功です。 DATABASE_URL=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] API_TOKEN=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] JWT_SECRET=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] 暗号化前の一時ファイルは削除します。 rm .env.plain この時点で、Git 管理する対象は .env.sops.env です。 平文の .env や .env.plain ではありません。 復号して .env を生成する 復号できるか確認します。 sops decrypt .env.sops.env 以下のような出力が得られれば成功です。 DATABASE_URL=postgresql://demo_user:demo_password@localhost:5432/demo_db API_TOKEN=dummy-api-token JWT_SECRET=dummy-jwt-secret 問題なければ、 .env に出力します。 sops decrypt .env.sops.env > .env chmod 600 .env これでアプリケーションが読む .env が生成されます。 cat .env 出力例は以下のとおりです。 DATABASE_URL=postgresql://demo_user:demo_password@localhost:5432/demo_db API_TOKEN=dummy-api-token JWT_SECRET=dummy-jwt-secret mise task で .env 生成を標準化する 毎回 sops decrypt .env.sops.env > .env と入力するのは手間です。 そこで、 mise.toml にタスクを追加します。 [tasks."env:render"] description = "Generate .env from encrypted env file" run = ''' set -euo pipefail sops decrypt .env.sops.env > .env chmod 600 .env echo "generated: .env" ''' [tasks."env:decrypt"] description = "Print decrypted env to stdout" run = "sops decrypt .env.sops.env" これで、開発者は次のコマンドだけで .env を生成できます。 mise run env:render 以下のような出力が得られれば成功です。 % mise run env:render [env:render] $ sops decrypt .env.sops.env > .env generated: .env 復号結果を標準出力で確認したい場合は、次を使います。 mise run env:decrypt 以下のような結果が得られれば成功です。 % mise run env:decrypt [env:decrypt] $ sops decrypt .env.sops.env DATABASE_URL=postgresql://demo_user:demo_password@localhost:5432/demo_db API_TOKEN=dummy-api-token JWT_SECRET=dummy-jwt-secret VSCode で暗号化された .env を編集する 暗号化済みファイルを編集する場合は、 sops edit を使います。 VSCode で編集する場合は、次のようにします。 SOPS_EDITOR='code --wait' sops edit .env.sops.env 実行すると /var/folders/s7/86599dyd1g5clgw4f7l3d2840000gn/T/3982786129/.env.sops.env のような一時ファイルが VSCode で開かれます。 適宜編集して保存した後、ファイルを閉じると .env.sops.env が再暗号化されます。 これも mise task にしておくと便利です。 [tasks."env:edit"] description = "Edit encrypted env file with VSCode" run = "SOPS_EDITOR='code --wait' sops edit .env.sops.env" 実行します。 mise run env:edit EMBEDDING_API_TOKEN などの値を適宜書き換えて保存し、VSCode を閉じます。 .env.sops.env が再び暗号化された状態で保存されれば成功です。 DATABASE_URL=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] API_TOKEN=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] EMBEDDING_API_TOKEN=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] JWT_SECRET=ENC[AES256_GCM,data:...,iv:...,tag:...,type:str] 最終的な mise.toml 例 最小構成の mise.toml は次のようになります。 [tools] sops = "3.12.2" azure-cli = "2.84.0" [tasks."env:render"] description = "Generate .env from encrypted env file" run = ''' set -euo pipefail sops decrypt .env.sops.env > .env chmod 600 .env echo "generated: .env" ''' [tasks."env:decrypt"] description = "Print decrypted env to stdout" run = "sops decrypt .env.sops.env" [tasks."env:edit"] description = "Edit encrypted env file with VSCode" run = "SOPS_EDITOR='code --wait' sops edit .env.sops.env" このファイルをプロジェクトに置いておけば、開発者が覚えるコマンドは少なくなります。 mise install mise run env:render 新規メンバーが入ったときの手順 新規メンバーが入ったときは、次の手順でセットアップできます。 git clone <repository-url> cd <repository-name> mise install az login mise run env:render もちろん、「キー コンテナー暗号化ユーザー」などの Key Vault 権限は事前に必要です。 発展：shared / secret / local に分ける 実際のチーム運用では、すべての値を1つの .env.sops.env に入れるより、値の性質ごとに分けたほうが扱いやすい場合があります。 例えば、次のように分けます。 .env.shared # チームで共有してよい非秘密情報 .env.secret.sops.env # SOPSで暗号化した秘密情報 .env.local # 個人用の上書き設定 .env # 最終的に生成されるファイル この場合の考え方は次の通りです。 ファイル Git管理 用途 .env.shared する チームで共有してよい非秘密情報 .env.secret.sops.env する SOPSで暗号化した秘密情報 .env.local しない 個人のローカル上書き設定 .env しない アプリケーションが読む生成物 この構成にすると、非機密情報の差分が読みやすくなります。 一方で、ファイルが増えるため、最小構成よりは運用ルールが必要になります。 例えば、mise task は次のようになります。 [tasks."env:render"] description = "Generate .env from shared, encrypted secret, and local env files" run = ''' set -euo pipefail tmp_secret="$(mktemp)" cleanup() { rm -f "$tmp_secret" } trap cleanup EXIT sops decrypt .env.secret.sops.env > "$tmp_secret" { cat .env.shared printf "\n" cat "$tmp_secret" if [ -f .env.local ]; then printf "\n" cat .env.local fi } > .env chmod 600 .env echo "generated: .env" ''' まとめ SOPS を使うと、 .env 形式のファイルを暗号化して Git 管理できます。 Azure Key Vault を組み合わせることで、復号できる人を Azure 側の権限で制御できます。 さらに mise を使うことで、SOPS と Azure CLI の導入、そして .env の生成コマンドをチームでそろえられます。 最小構成は次の通りです。 .env.sops.env # 暗号化された.env。Git管理する .env # 復号して生成する.env。Git管理しない .sops.yaml # SOPS設定 mise.toml # ツールとタスク定義 開発者が実行するコマンドは、最終的にはこれだけにできます。 az login mise install mise run env:render 環境変数の管理はチーム開発において重要な課題です。 いざ開発に入ると、 .env の値をチャットで共有してしまったり、誰が最新の値を持っているのかわからなくなったりします。 今回の構成を使うことで、Git 管理と Azure Key Vault の権限管理を組み合わせながら、チームで同じ手順で .env を生成できるようになります。 参考資料 SOPS のドキュメント https://getsops.io/docs/ SOPS の GitHub リポジトリ https://github.com/getsops/sops SOPS Azure KMS https://getsops.io/docs/usage/identities/azure-kms/ dotenvx Encryption https://dotenvx.com/docs/quickstart/encryption/ SOPS Config File https://getsops.io/docs/usage/identities/config-file/ mise のインストール方法 https://mise.jdx.dev/installing-mise.html 執筆： @aoki.naoto レビュー： @yamada.y （ Shodo で執筆されました ）

こんにちは、事業開発室の里中裕輔です。 本記事では、LayerXさんと共同で開催した「AIエージェント設計勉強会 〜long-runningタスクの設計と実践知〜」 についてレポートします。 勉強会の概要 本勉強会は、LayerXさんと電通総研が共同で開催している、AIエージェントに関するエンジニア向けの勉強会イベントです。その第2回目として、2026年05月28日（木）に、long-runningタスクに関する勉強会を開催しました。 生成AIの実務活用が広がるなかで、AIエージェントを「試す」段階から「本番運用に載せる」段階へと進める動きが増えています。一方で、実際にプロダクトや業務へ組み込もうとすると、単発のタスク自動化とは異なる設計論点が数多く見えてきます。今回の勉強会では、LayerX と電通総研のエンジニアが登壇し、AIエージェントを継続的に動かすための設計・実装・運用の知見を共有しました。 会場はLayerXさんのオフィスをお借りして、40人程度の方に参加していただきました。 勉強会の内容としては以下のとおりです。 ・株式会社LayerX『恩田 壮恭』さん： 「long-runningタスクの設計と実践知」 ・株式会社電通総研『袴田 時生』： 「DeepResearchをプロダクトに組み込むためのノウハウ」 ・懇親会 long-runningタスクの設計と実践知 恩田さんからは、長時間のタスク（long-runningタスク）を完遂させるために、どのような方法論があるのかが発表されました。long-runningタスクを自律的に完遂するため、AIエージェントはタスクを分割して計画を立て、分解されたタスクを「1つずつ」順番に処理します。しかし、AIエージェントは確率的な処理であるため、数多くのタスクを順番に処理すると間違いが少しずつ蓄積され、処理が破綻することがあります。 こちらの発表では、処理を破綻させないための方法論について3つの論文を紹介する形で説明されました。いつリトライすれば良いのか、複数の異なるアプローチでタスクを処理させ、答えが一致すればその処理結果の確度が高くなるなど、興味深い知見が共有されました。 DeepResearchをプロダクトに組み込むためのノウハウ 袴田からは、Deep Research システムをプロダクトに組み込むためのノウハウが発表されました。 おそらく、多くの方はブラウザのチャットUIで Deep Research システムを利用することが大半だと思われます。そのため、Deep Research システムも一種の生成AIモデルであると想像する方がほとんどではないでしょうか。特に最近は、チャットUI上に「Thinkingモデル」と表示されることもあり、この傾向はより一層強まっていると言えるでしょう。 その想像とは裏腹に、Deep Research システム は、「検索エンジン」「Webクローラー」「キャッシュ」「API連携」「ツール制御層」「エラー処理」など、多くのコンポーネントを組み合わせて構築します。そのため、良いDeep Research システムを構築するためには、多様なシステムエンジニアリングのノウハウが必要です。 今回の発表では、「企業のデューディリジェンス」を Deep Research システムを使って構築する内容が話され、自律と制御のトレードオフや検索エンジンのノウハウなどが紹介されました。 発表スライドはこちらで公開されているので、興味のある方はご覧ください。 https://speakerdeck.com/tokio007/deep-researchwopurodakutohezu-miip-mutamenonouhau 懇親会 懇親会も多くの方に残っていただき、発表内容に関する質疑や広くAIについてのディスカッションができました。 電通総研のメンバーとしては、Deep Research に関する話題を中心に会話しておりましたが、やはり皆さん、既存のDeep ResearchのAPIがコストの面で使いずらいという印象をお持ちでした。一方、参加者の皆様の企業でも、プロダクトに Deep Research を組み込みたいというお話もありましたので、Deep Research のAPIについて、コストや使いやすさの観点から今後の動向を注視していきたいと思いました。 私自身としても、多様な視点で会話することができ、有意義な懇親会だったと感じております。 まとめ 今回は、LayerXさんと電通総研が共同で開催した 「AIエージェント設計勉強会 〜long-runningタスクの設計と実践知〜」 についてレポートしました。 私が勉強会を通じて感じたのは、多くの方々の情報収集において Deep ResearchシステムやThinkingモデルは身近なものになったということでした。2月にもイベントを開催しましたが、その際はまだエンジニアの方々のほうがよく使われているような印象を受けました。この3か月間で、AIツールの活用が非エンジニアのユーザーにまで急速に広がったことを実感しました。 そんな状況の中で、コストの面や機密情報の投入など、Deep Researchシステムを使う上での課題が、まだまだ解消されていないことも改めて感じました。引き続き、自社プロダクトの機能に生成AIやLLM、AIエージェントを組み込み、継続的にユーザーへ価値を届けることができるように先端技術の情報収集を続けていこうと強く思えました。 少し余談ではありますが、電通総研 事業開発室のAIチームは昨年のNeurIPSコンペで優勝を果たしており、Deep Research システムの最先端の内容をお届けできたかなと感じております。 https://www.dentsusoken.com/news/release/2025/1219.html 電通総研は、引き続きこのような勉強会を開催する予定ですので、興味ある方はぜひご参加ください。 https://engineersguild.peatix.com/ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @satonaka.yusuke レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

こんにちは、事業開発室の里中裕輔です。 本記事では、Engineers GUILDのご紹介と、その8回目のイベントであった Engineers GUILD Vol8 「世界トップの学会コンペの優勝者が解説する、最先端のDeep Researchシステムのアーキテクチャ」 についてレポートします。 Engineers GUILDとは Engineers GUILD（エンジニアズ・ギルド）は「エンジニアの、エンジニアによる、エンジニアのためのギルド」を掲げる、分野横断型の技術コミュニティです。現場で活躍するエンジニア同士が、副業や越境活動を通じて学び合い、つながり、共創できる場を目指します。 https://engineersguild.peatix.com/ その第8回目として、2026年04月22日（水）に、Deep Researchに関する勉強会を開催しました。 2025年2月に Deep Research が登場し、市場調査、競合分析、先端技術調査など、Web上を調査する様々な場面で活用されています。このように、ブラウザのチャットUIで利用する場面が多い一方で、システムへの組み込みも検討されています。 Deep Researchをプロダクトや業務システムに組み込もうとすると、すぐに大きな壁にぶつかります。商用APIを利用すればスピーディに始められる一方で、継続利用にはコスト面のハードルがあります。また、自社で内製しようとしても、Deep Researchのアーキテクチャは十分に公開されていないケースが多く、検索、推論、ツール制御、エラー処理まで含めて自分たちで設計するのは簡単ではありません。だからこそ、「Deep Researchをどう作るのか」をアーキテクチャの観点から理解することには、大きな価値があります。 タイトルにもありますが、我々のチームは昨年のNeurIPSコンペで優勝を果たしました。 https://www.dentsusoken.com/news/release/2025/1219.html 今回の勉強会は、私たちのチームが注目している「DR Tulu」という論文で公開された Deep Research システムのアーキテクチャについて解説し、参加者の方々と活発に議論できた会になりました。 勉強会の内容としては以下のとおりです。 ・電通総研『尾崎 尚憲』さん： 「DR Tuluのアーキテクチャ解説」 ・懇親会 DR Tuluのアーキテクチャ解説 尾崎さんからは、オープンソース技術で構築されたDeep Research システムである「DR Tulu」に関する講演がありました。今回は、モデルの解説のような理論には踏み込まず、どういったアーキテクチャであるのかの解説がメインでした。 多くの方にとって、Deep ResearchはブラウザのチャットUIから利用するものだと思います。そのため、一見すると「高性能な生成AIモデルが、うまく調査してくれている」と見えるかもしれません。しかし、実際のDeep Researchは単体のAIモデルではありません。 検索エンジン、Webクローラー、キャッシュ、API連携、ツール制御層、エラー処理など、複数のコンポーネントが連携して動く“調査システム”です。つまり、良いDeep Researchを作るには、モデルの知識だけではなく検索・取得・制御・復旧まで含めた総合的なシステムエンジニアリングの力が求められます。 尾崎さんより、「DR Tulu」を題材に全体のアーキテクチャの概要や、システムエンジニアリング上の10個の工夫など、アーキテクチャ面の紹介がされました。 発表スライドはこちらで公開されているので、興味のある方はご覧ください。 https://speakerdeck.com/hisanoriozaki/dr-turu-akitekutiyawan-quan-jie-shuo 懇親会 懇親会も多くの方に残っていただき、発表内容に関する質疑や広くAIについてのディスカッションができました。今回、アーキテクチャにフォーカスしたイベントだったので、日ごろAIエージェントの開発を行っている方に多く参加していただける会になったと思います。 意外だったのは、モデルの学習方法や評価方法などの議論も行われたことです。事前の想定では、アーキテクチャや実装面での工夫に関する議論が多くなると考えていたので、最初は不思議に思いました。参加者の方々と会話を進めると、AIの導入を推進しているエンジニアの方々は、各ステークホルダーに「そのシステムがなぜそういった出力をしたのか」を説明する責任を負っており、モデルのアーキテクチャについての知識も必要とされているということがわかりました。 そのため、エンジニアの方々もモデルの学習方法や評価方法などに踏み込んだ質問をされるということになりました。 私自身としても、多様な視点で会話することができ、有意義な懇親会だったと感じております。 まとめ 今回は、Engineers GUILDのご紹介と、その8回目のイベントであった 「世界トップの学会コンペの優勝者が解説する、最先端のDeep Researchシステムのアーキテクチャ」 についてレポートしました。 私が勉強会を通じて感じたのは、エンジニアの方々の情報収集において Deep Researchシステムは身近なものになったということでした。そんな状況の中で、コストの面や機密情報の投入など、Deep Researchシステムを使ううえでの課題があることを感じました。 Deep Researchは、単なる便利な調査ツールから、プロダクトや業務システムに組み込まれる“知的基盤”へと進化しつつあります。その流れの中で、生成AI、LLM、AIエージェントをどのように設計し、どう運用し、どう継続的に価値へつなげるのか。今回の勉強会は、その問いに向き合う非常に良い機会となりました。 電通総研は、引き続きこのような勉強会を開催する予定ですので、興味ある方はぜひご参加ください。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 執筆： @satonaka.yusuke レビュー： @kinjo.ryuki （ Shodo で執筆されました ）

はじめまして。エンタープライズ第二本部 プラットフォームエンジニアリング部 2年目の菊池です。業務ではAIサポートセンターとして 生成AI / LLM 活用案件やdJグループ内の生成AI利活用推進などを行っています。 この記事は、社内に幾多ある勉強会のひとつである『25卒技術会』での発表内容をもとに執筆されています。 『25卒技術会』では隔週火曜日に会議室に集まり、ブックリーディングと自由テーマ発表の2軸で各々の学びを共有し合っています。このたび、外部向けの施策として自由テーマ発表から不定期でテックブログを書いていく運びとなりました。ちなみに、この会の主催者はテックブログ常連でもある同期の大岡叡さんです。今後、下記の技術会メンバーからも記事の投稿がある予定ですので、お楽しみに。 大岡 叡 ／菊池 祥汰 ／ 伊藤 真幸 ／ 植木 信輔 ／ 上原 辰徳 ／ 今橋 輝 ／ 渡邉 真太郎 ／ 段下 幸太郎 自律駆動する部下は実現するか — OpenClaw という予兆 ローカル LLM の 3 つの強み 目指す世界 — 24 時間 365 日 動く株式エージェント ローカル LLMの現在地を探る 道具立て — Ollama / Gemma 4 ベースライン — 単純な線形回帰による数学的解決 実験 結果と考察 — Gemma 4 vs Gemini 現在地の見立てと展望 おわりに 2026/06/04追記 自律駆動する部下は実現するか — OpenClaw という予兆 2026 年の年明けから、 OpenClaw （旧 MoltBot） と呼ばれる能動的な AI エージェントが話題になっています。 OpenClaw は、特定のディレクトリに操作権限を与えると、AI が「次に何をすべきか」を自分で考えながら、24 時間 365 日、自律的に動き続けるタイプのエージェントです。人間が一手ずつ指示するのではなく、目的だけ渡せば手段を自分で組み立てていきます。 目的を渡せば、AI が「次にすべきこと」を自分で考え、実行し、結果を見て改善する。これが 24 時間 365 日回り続ける AI の操作をいちいち承認する操作も不要。AIの成果物を確認しレビューする 人間という最大のボトルネックを排し 、AI を本当に「 自律駆動する部下 」のように位置づけられる可能性が見えてきました。こうした動きは、すでに一人歩きを始めており、AI エージェントだけが集う SNS「 Moltbook 」なども話題を呼んでいます。Reddit のように投稿やコミュニティが並ぶのに、書き込むのはすべて AI エージェントで、人間は観察者としてしか入れません。サービス開始から数日で150万を超えるエージェントが集まり、その中では AI 同士が共同体や、ときに宗教めいたものまで自発的に作り始めたと 報じられ ています。 AIはチャットボットとして人間に律速されるフェーズを脱し、エージェント駆動する時代へとのシフトが始まりつつあります。 その一方で、大きなリスクがあります。それが API コスト です。AI を長時間・高頻度で回すほど、ランニングコストは跳ね上がっていきます。これは特に金融系のユースケースでROIを測定する際に重くのしかかってきます。 必然的に、 ローカル LLM が選択肢に上ってきます。通常私たちが利用している ChatGPT や Claude（本記事ではまとめてクラウド LLM と呼びます）は、各社のサーバ上の計算資源（メモリや GPU など）を使って動いています。便利な反面、入力は社外に送られ、使うほど従量課金が積み上がっていく。これを自分の手元のマシンだけで完結させようというのが、ローカル LLM の発想です。 ローカル LLM の 3 つの強み 私がローカル LLM の価値として最も強く押し出したいのは、次の 3 点です。 データが外部に出ていかない（セキュア） — クラウド API は入力がすべて外部に送信されます。機密情報や個人データ、API キーを扱う場合、ともすれば致命的になりえます。ローカルなら、扱うデータは自分の環境から出ません。 完全自律で回しても API コストが爆発しない — 長時間・高頻度で動かすほどクラウド API の従量課金は膨らみます。最近は各種AIベンダーも投資を回収するフェーズに入ってきており、円安も加わってクラウドAPIのコスト体系はかなり向かい風です。ローカルLLMなら、追加コストは電気代だけ。円安の煽りを受けにくいだけでも儲けものです。 買い切った GPU を遊ばせない — これは減価償却的な観点ですね。ゲーム用に買った GPU をAPI 利用料の節約という観点で使い回すことができれば、買い切りの出費を長く活かし続けられます。 ローカル LLM の 3 つの強み。（1）データが外に出ない （2)API コストが爆発しない （3）買い切った GPU を遊ばせない 目指す世界 — 24 時間 365 日 動く株式エージェント さて、この自律駆動エージェントの終着点を、私は24 時間 365 日、世界中のニュース・企業のプレスリリース・今朝の報告書を監視し続け、 株の自動売買を行うエージェント だと見ています。短期投資は分刻み・秒刻みで状況が動くので、「いま買いか、買いでないか」を常に判断させたい＋低コストで回しっぱなしにしたいという需要があります。ローカル LLM の優位性は明確です。 加えて、セキュリティ面でも、ローカル LLMを用いれば自身のポートフォリオや API キーが外部に流出するリスクを、限りなくゼロに近づけられます。金融データを扱う以上、セキュリティは最優先事項です。ローカル LLM の性質と、このタスクの要件は強く噛み合います。 最も重要なのが ランニングコスト です。API 料金が発生すると、コストに見合うリターンを得なければならず、強気（ハイリスクハイリターン）な投資を余儀なくされてしまいます。これは運用手数料の高い投資信託を保有しているときの感覚に近く、最も忌避すべき条件です。だからこそ、追加コストを電気代だけに抑えられ、なおかつまともな回答精度が得られるのであれば、ローカル LLMは非常に合理的なブレインとなりうるでしょう —— まともな回答精度が得られるのであれば、ですが。 一方で、現実にそういった話はなかなか聞きません。なぜなのでしょう。前置きが長くなりましたが、今回の記事ではここに切り込んでいこうと思います。 ローカル LLMの現在地を探る 投資エージェントをいきなり走らせるのは無理があります。買いと判断した銘柄が上がったか下がったか、その答え合わせには数か月かかりますし、コーディングも大規模になってしまいます。 そこで本記事は、ローカル LLM の現在地を知るための実験として、 物件のスペックから賃料を予測する という擬似的な経済価値判断タスクを解きます。無数の物件スペック情報から適正な価格を予測し、その予測価格と実際の価格を照合して、コスパの良い物件を検出する。スペックから想定される賃料より実際の賃料が安ければ、それはコスパが良い物件とみなし、ユーザーに提案するというものです。 両者の構造を並べると、次のように対応します。 ステップ 物件コスパ判定（題材） 株式自動売買（本命） 外部データ ローカルにキャッシュした物件情報 株価 API・ニュース・朝の報告書 LLM の価値判断 スペックから適正賃料を予測 情報から買い/売り/様子見を判断 指標化 コスパスコア（実価÷予測） 投資シグナル 正解突合 即時 数日〜数か月後 株価予測は検証に長い期間が必要です。一方、この物件タスクは、構築と答え合わせのサイクルが短く、実装も容易です。ローカル LLM の現在地を知る、という目的にはこちらが合っていました。 道具立て — Ollama / Gemma 4 ローカル LLM 基盤には Ollama を用いました。Ollama はよく「Docker for LLM」と呼ばれます。実際、開発者は元 Docker のエンジニアで、 ollama pull でモデルを取得し ollama run <model> で対話を始める操作感は Docker そっくりです。 起動すると、 localhost:11434 に REST API サーバーが立ちます。OpenAI / Anthropic 互換のエンドポイントを備えているため、既存コードの接続先を差し替えるだけでローカルモデルに切り替えられます。 モデルは Gemma 4 を用いました。Google が 2026 年 4 月に公開した オープンウェイトのモデル で、Gemini と同じ研究基盤から生まれた、画像も扱えるマルチモーダルモデルです。 Gemma 4 の特徴として MoE（Mixture of Experts、混合エキスパート） の採用があります。今回の主役 26B は、総パラメータが約 26B ありながら、推論時に実際に使うのは約 3.8 B だけです。すなわち、大型モデルの賢さを、より軽い計算量で出せるというわけです。 もうひとつの個性が、 量子化 との相性です。Gemma 4 は、いずれ圧縮されることを見越して学習する QAT（Quantization-Aware Training、量子化を考慮した訓練）を採っています。おかげで、重みの精度を 16 bit から 4 bit へ落としても品質の劣化が小さく、必要メモリを 4 分の 1 ほどに圧縮できます。本記事でローカルに落とした 4-bit 量子化版（ gemma4:26b ）も、この仕組みの上に成り立っています。 Ollama で扱える主なサイズは、次のとおりです。 Ollama タグ 構成 パラメータ（推論時 / 総） サイズ（4-bit） コンテキスト 位置づけ gemma4:e2b 軽量 2.3B / 5.1B 7.2 GB 128K 最小・スマホ等の省メモリハード向け（本実験では未使用） gemma4:e4b （= latest ） 軽量 4.5B / 8B 9.6 GB 128K 軽量・まず試した gemma4:26b MoE 3.8B / 25.2B 18 GB 256K 中型・今回の主役 gemma4:31b Dense 30.7B / 30.7B 20 GB 256K 最大・最高性能 整理すると、Ollama と Gemma 4 の関係は次の図のようになります。Ollama がローカル LLM の実行基盤、Gemma 4 がその上で動くモデル本体です。 Ollama は実行環境、Gemma 4 はその上で動くモデル。クラウドに送らず、すべてローカル PC 内で完結する 題材アプリ「大田区コスパ物件ハンター」は、Claude Code を使った Vibe Coding で作り、UI は Streamlit でさっと組みました。物件データは各サイトの利用規約に配慮し、あらかじめローカルに保存しておいたキャッシュ（CSV）を入力として扱います。これを読み込み、各物件の相場家賃を LLM に予測させ、実賃料 ÷ 予測でコスパスコアを出すだけのアプリです。スコアが低いほど割安で、0.85 を下回った物件を「お買い得」としてユーザに提案します。 Streamlit で実装したアプリケーションUI。結果はローカル実行した gemma4:26b （直列）のもの。30 件の処理に約 10.9 時間を要した ベースライン — 単純な線形回帰による数学的解決 LLM を並べて競わせても、「どれもそれなりに賢い」で終わってしまうと考え、賃料を専有面積と駅からの徒歩分数の 2 変数だけで説明するシンプルな線形回帰モデルを用意し、ベースラインとすることで、各 LLM の推論能力を定量的に評価しました。 評価用の 30 件とは別に訓練用サンプル 200 件を用意し、最小二乗法で式を一本だけ当てはめました。 賃料(万円) ≒ 0.1898 × 専有面積(㎡) − 0.2021 × 徒歩(分) + 11.26 間取りも築年数も使わない非常にシンプルな式での実装です。訓練 200 件と評価 30 件は 1 件も重なっておらず（out-of-sample）、LLM 側も同じ 30 件を学習していないので、比較はフェアです。 精度は MAE（平均絶対誤差）・MAPE（平均絶対誤差率）・バイアス（誤差の符号付き平均。予測が高めか低めかの偏り）の 3 つで測り、コストはローカルを電気代換算（350 W × 31 円/kWh）、API をトークン単価に統一して記録しました。 そして LLM 側にも、同じ土俵に立ってもらいます。各物件について実際に投げているプロンプトは、次の全文です。素朴に「相場を教えて」と尋ねるのではなく、データから導いたアンカー（基準値と補正係数）を持たせ、例にならって 5 ステップの計算過程（Few-shot + Chain-of-Thought）を踏ませる作りにしています。 あなたは東京都大田区の賃貸相場に詳しい不動産アナリストです。 以下の推論例(例1〜例3)と同じ形式で step1→step5 を順に計算し、最後に賃料を算出してください。 アンカーは大田区2DK/2LDK 117件の訓練データから多重回帰で抽出した実データ係数です。 # 推定アンカー (基準: 中位駅×2LDK×3-5階建×築10-20年×徒歩10分 → 0.33 万円/㎡) ## 駅tier - 上位 (大森・大森町・蒲田・京急蒲田・洗足池): ×1.10 - 中位 (馬込・西馬込・池上・武蔵新田・千鳥町・梅屋敷・大岡山 等): ×1.00 - 下位 (雑色・矢口渡・平和島・下丸子・石川台・田園調布): ×0.90 ## 間取り - 2LDK: ×1.00 / 2DK: ×0.95 ## 階建 - 1-2階建(木造想定): ×0.88 / 3-5階建: ×1.00 / 6階建以上(RC想定): ×1.17 ## 築年 - 築0-10年: ×1.12 / 築10-20年: ×1.00 / 築20-30年: ×0.95 / 築30年+: ×0.92 ## 徒歩 - 徒歩10分基準で ±1分あたり ∓1% (例: 徒歩6分 → +4%、徒歩14分 → -4%) # 推論例(この5stepフォーマットを必ず踏襲) ## 例1: 蒲田駅 徒歩6分 / 2LDK 55㎡ / 築8年 / 8階建 step1 駅tier = 0.33×1.10 = 0.363 (蒲田=上位) step2 間取り = ×1.00 = 0.363 (2LDK) step3 階建 = ×1.17 = 0.425 (8階建 → RC想定) step4 築年 = ×1.12 = 0.476 (築8年 → 築0-10年) step5 徒歩 = ×1.04 = 0.495 (徒歩6分 → +4%) 賃料 = 0.495 × 55 = 27.2万円 推定家賃: 27.2万円 ## 例2: 池上駅 徒歩10分 / 2DK 42㎡ / 築22年 / 7階建 step1 駅tier = 0.33×1.00 = 0.330 (池上=中位) step2 間取り = ×0.95 = 0.314 (2DK) step3 階建 = ×1.17 = 0.367 (7階建 → RC想定) step4 築年 = ×0.95 = 0.349 (築22年 → 築20-30年) step5 徒歩 = ×1.00 = 0.349 (徒歩10分 → 基準) 賃料 = 0.349 × 42 = 14.7万円 推定家賃: 14.7万円 ## 例3: 雑色駅 徒歩14分 / 2DK 40㎡ / 築32年 / 2階建 step1 駅tier = 0.33×0.90 = 0.297 (雑色=下位) step2 間取り = ×0.95 = 0.282 (2DK) step3 階建 = ×0.88 = 0.248 (2階建 → 木造想定) step4 築年 = ×0.92 = 0.228 (築32年 → 築30年+) step5 徒歩 = ×0.96 = 0.219 (徒歩14分 → -4%) 賃料 = 0.219 × 40 = 8.8万円 推定家賃: 8.8万円 # 推定対象物件 - 間取り: {間取り} - 専有面積: {専有面積(㎡)}㎡ - 最寄り駅: {最寄り駅} {徒歩N分} - 築年数: {築N年} - 階建: {階建} 上記5stepを順番に計算し、**最終行に厳密に** `推定家賃: <数値>万円` (小数1桁) の形式で1値だけ出力してください。 ※ プロンプト冒頭のアンカー（基準 0.33 万円/㎡ と各補正係数）は、線形回帰ベースラインの訓練に使った 200 件と同種の サンプルに多重回帰をかけ、統計的に抽出した実データ係数です。つまり、ベースラインと同じ訓練データの知識を LLM 側にも与えたうえで勝負させています。 実験 検証環境は以下のとおりです。 OS: Windows 11 Home / CPU: Intel Core i7 14700KF / RAM: 32 GB / GPU: GeForce RTX 5060 Ti（VRAM 16 GB） Python: 3.13 / 主要ライブラリ: ollama pandas streamlit 評価データ: ローカルにキャッシュした大田区 2DK/2LDK の物件情報 30 件（全実験で固定） 最初は、VRAM 16 GB に余裕で収まる軽量モデル gemma4:e4b （9.6 GB）から試したのですが、賃料予測の手前の簡単な質問でつまづきました。試しに「大田区で有名な駅を 1 つ教えて」と聞いてみたところ、 gemma4:e4b は自信満々にこう答えました。 大田区で特に有名な駅の一つは、大田駅（おおたえき）です。 （中略）東急大井町線などが乗り入れており、大田区の主要な交通結節点の一つとなっています。 その他、エリアの特性によっては、新大田駅なども利用される大きな駅です。 「大田駅」も「新大田駅」も、実在しません。しかも、その架空の駅に「東急大井町線が乗り入れる交通結節点」というもっともらしい乗り入れ情報まで添えています。典型的なハルシネーションですね。地名すらこの調子では、複雑なスペックから経済価値を判断させるのは到底無理だということで、軽量モデルは早々に候補から外れました。 同じ質問を、ひとつ上の gemma4:26b に投げると、答えが変わります。 大田区で最も有名な駅といえば、蒲田駅（かまたえき）です。 大田区の最大のターミナル駅であり、JR、京急、東急といった複数の路線が乗り入れる交通の要所です。 概ね意図どおりの回答が得られました。 最低限の精度を求めるには、 26b が要るようです。 gemma4:26b は「蒲田駅」と正答。乗り入れ路線も正確な回答になっている。 ところが、 gemma4:26b を手元の RTX 5060 Ti で動かそうとして、最初の壁にぶつかります。 gemma4:26b は 4-bit 量子化でも約 17 GB あり、VRAM 16 GB にわずかに収まりません。Ollama は収まらない分（約 35 %）を RAM 側に退避させ、その部分を CPU で計算します。結果、GPU と CPU を行き来する構成になり、計算時間が大幅に増えてしまいました。 ここで重要なのは、 VRAM 不足が線形の劣化ではなく崖 だということです。 理由は、LLM の推論がメモリ帯域に律速されるからです。推論の中身は、膨大な重みをメモリから読み出して計算する処理の繰り返しで、ボトルネックは計算量よりも読み出しの速さにあります。GPU の VRAM はこの読み出しが桁違いに速い一方、CPU 側へ退避した層は、それよりずっと帯域の狭いシステム RAM を経由します。 約 17GB のモデルが 16GB の VRAM に収まらず、Ollamaによって自動的にモデルの 約 35% が RAM/CPU へ退避する結果に。処理速度は VRAM 容量を超えた瞬間に崖のように急落する 私の PC のスペックはごくごく一般的なゲーミング用ですので、 ローカル LLM を前提とした十分な VRAM を積んだ GPU でないとまともな推論能力は得られない というのが 2026 年 6 月時点の現在地となりそうです。 が、さすがにこの結果では終われないので、急遽 Google AI Studio から Gemma 4 の API を叩く形に切り替えました。これにより、Google 側が用意した計算資源を借りて、Gemma 4の26Bと31Bという大きめのモデルを（無料で）動かすことができます。一旦手元のハードの制約を外し、モデルそのものの実力を見にいきました。 結果と考察 — Gemma 4 vs Gemini 評価 30 件での実測をまとめます。ベースライン（線形回帰）は MAE 2.826 / MAPE 19.62 % / バイアス +0.092 でした。 モデル 実行環境 時間 コスト MAE MAPE バイアス 線形回帰ベースライン — — — 2.826 19.62% +0.092 Gemini 2.5 Flash-Lite API・並列×8 10.6 秒 2.10 円 3.177 17.42% −2.203 Gemini 2.5 Flash-Lite API・直列 64.9 秒 2.15 円 3.127 17.28% −2.167 Gemini 3.5 Flash API・並列×4 93.6 秒 29.61 円 3.157 17.11% −2.283 Gemini 3.5 Flash API・直列 約 5.3 分 28.97 円 3.340 18.24% −2.367 Gemma 4 31B Dense AI Studio・直列 約 27 分 0 円 3.317 18.25% −2.39 Gemma 4 26B a4b AI Studio・直列 約 1.4 時間 0 円 3.213 17.58% −2.24 Gemma 4 26B ローカル・直列 約 10.9 時間 118.21 円 11.566 71.14% −6.604 同じ 30 件でも、実行環境によって所要時間は大きな差になる。最速のクラウド並列と最遅のローカル直列の開きは、約 3,700 倍 比較対象とするクラウドLLMは、 Google 系列のモデルでそろえました 。先述の通り、Gemma 4 は Gemini と同じ研究基盤から生まれたモデルなので、ある程度公平な比較と言えるでしょう。選んだのは次の 2 つです。 Gemini 2.5 Flash-Lite （軽量クラウドモデル） — Gemma 4 とベンチマーク帯がほど近く、「同じくらいの賢さなら、ローカルとクラウドのどちらが割に合うか」というコスト対効果と、ローカルの代替になりうるかを見る役です。 Gemini 3.5 Flash （最新ハイエンド） — つい先日、2026 年 5 月 19 日の Google I/O 2026 で GA になったばかり。「コストをかけて上位モデルにすれば、差は埋まるのか」という上限を確認する役です。世代の 3.1 Pro 比で大半のベンチマークを上回りながら、 価格は約 25 % 安く、出力は約 4 倍速い とされています。並列4件になっているのは1分あたりのレート制限がGemini 2.5 Flash Liteよりも厳しいため。 考察を 3 点 挙げます。 まず、 Ollamaローカル実行は、実行時間もコストも突出して重い。 同じ 30 件に対して、Gemini 2.5 Flash-Lite は並列で 10.6 秒・約 2 円。ローカルの 26B は約 10.9 時間・118.21 円。速度で約 3,700 倍、コストで約 60 倍の差です。VRAM溢れが発生するような欲張りなモデル選定を行った場合、という枕詞はつきますが、「追加コストは電気代だけだから安い」という直感には反する結果となりました。 一方で、これは「VRAM に収まらなかったとき」の数字でもあります。仮に RTX 4090（VRAM 24 GB）のように、 gemma4:26b （約 17 GB）がまるごと載る GPU だったらどうでしょう。ここでは、AI Studio 版の 26B と同じ約 1.4 時間で終わると仮定して、電気代を試算します。 計算式は 消費電力(kW) × 時間(h) × 31 円/kWh （東京電力 従量電灯B 第2段階）です。時間を 1.4 時間に固定し、消費電力の前提だけを 3 通り変えてみると、以下の表のようになります。 消費電力（PC 全体の目安） 計算式 30 件の電気代 350 W（本実験のローカル機と同じ前提） 0.35 × 1.4 × 31 約 15 円 450 W（RTX 4090 の TDP＝GPU 単体ピーク） 0.45 × 1.4 × 31 約 20 円 600 W（4090 を積んだ PC 全体の高負荷時） 0.60 × 1.4 × 31 約 26 円 RAM 退避したケースに対して、4 分の 1 以下にとどまります。しかも 1.4 時間はクラウド側の所要時間で、フル GPU ならさらに速く・安くなる可能性が高い。とはいえ、Gemini 2.5 Flash-Lite が 2.1 円に収まることを鑑みると、 「ローカル LLM は電気代だけだから安い＝APIコストをGPU投資によって回収できる」という神話は完全に否定された と言えるでしょう。 同じ 30 件を Gemini 2.5 Flash-Lite の並列実行で処理した結果。所要時間は 10.6 秒 ふたつ目。 どの LLM も、面積と徒歩だけの線形回帰（MAE 2.826）に、MAE で勝てていません。 何十億ものパラメータを持つ最新モデルが、2 変数のごく単純な式に及びませんでした。 一方で、指標MAPEを変えると景色は反転します。率で見る MAPE では、LLM 群はそろって 17 % 台に収まり、ベースラインの 19.62 % を下回りました。 平均誤差では負け、率で見れば勝っている。 MAE は高額物件の絶対誤差に引っ張られ、MAPE は安い物件の外れも対等に扱います。どちらの物差しを採るかで、勝者がそのまま入れ替わるわけです。これは、「どの指標で測るか」を決めることが、結論そのものを決めてしまう、という実務的な教訓ですね。 MAE で負けた理由はおそらく、賃料というタスクがそもそも面積に対してほぼ線形で、「避けられない複雑さ」が低いからでしょう。タスクが単純なとき、単純なモデルが分散の大半を説明してしまいます。そこに LLM を持ち込むと、かえってノイズを上乗せする結果に終わってしまいます。 最後に、 最新・高価なモデルほど効く、とは限らないことが浮き彫りになりました。 Gemini 3.5 Flash は、Gemini 2.5 Flash-Lite 比約 14 倍のコスト（約 30 円）をかけて、精度はほぼ横ばいでした。少なくともこの物件タスクでは、価格に見合う上積みは得られなかった、ということです。 肝心の良コスパ物件判定ですが、コスパスコア（実賃料 ÷ 予測相場）が 0.85 を下回る物件を「お買い得」として抽出したところ、安定して動いたモデルはどれもほぼ同じ顔ぶれを拾いました。筆頭は JR 京浜東北線・蒲田駅 徒歩 4 分の 2DK（実賃料 8.5 万円／予測相場 11.2 万円＝スコア約 0.76）で、これに鵜の木・パレスフロラシオンの 2DK が続き、お買い得はおおむね 3 件前後でした。もちろん今回取り扱った物件のスペックは限定的ですので詳細を吟味する必要はありますが、第一層の捌きとしては十分に絞り込めているのではないでしょうか。引っ越しを検討している同僚に試してもらってFBをもらっていけば、案外実用的なアプリとして運用できるかもしれません。 現在地の見立てと展望 実験を踏まえ、ローカル LLM の現在地の見立てを述べます。 現時点での結論として、実用的なのは Google AI Studio から Gemma 4 を叩く 形でしょう。学習利用という枷こそあれど、無料で使え、Google 側の計算資源を用いて大きめのモデルも問題なく動きます。少なくとも、家庭用 GPU で 17 GB 級のモデルと格闘するよりは、ずっと現実的な選択肢でしょう。ただし、 この無料枠がいつまで続くかは分かりません 。AI企業は投資を回収するフェーズに入っており、利益にならない計算資源をどこまで無料で使わせてもらえるかは完全にGoogle側の経営判断に委ねられています。 次点は Gemini 2.5 Flash Lite などの軽量・高速モデル を用いる ことでしょう（この記事の執筆中に EOL が発表されてしまいましたが……移行先は Gemini 3.1 flash Lite ですかね）。Gemma 4 は、Gemini 2.5 Flash-Lite のような軽量・高速なクラウドLLMと比べて、推論力では一段劣る印象でした。費用対効果を考えると、軽量なクラウドLLMは安くてリターンの大きい投資であると考えます。少なくとも私ならこの選択肢を選ぶでしょう。 繰り返しになりますが、今回の検証はローカルLLMの「現在地を探る」ことを目的としています。ビッグテックによるLLMの開発競争は、さながら米露の宇宙開発の様相。ローカルLLMについても、量子化や知識蒸留技術の進歩によって（なんならムーアの法則的な計算資源面の改良にも期待しつつ）、さらなる軽量化・ベンチマークスコア向上が期待されます。特に今回題材に挙げた Gemma 4 については Gooole がかなり意欲的に開発を進めているので、今後とも注視していきたいです 今後の課題としては、本命のタスクである株式投資エージェントによるベンチマークでしょうか。今回、最新の Gemini 3.5 Flash も同じ土俵で回しましたが、賃貸予測タスクでは割高なだけで、明確な上積みはありませんでした。ただ、3.5 Flash の本領は、エージェントや金融まわりの複雑なタスクにあるとされています（金融エージェント向けのベンチマーク（ Finance Agent v2 ）では、前世代の Gemini 3.1 Pro を大きく上回ったと報告されています）。だとすれば、その差が出るのは今回のような単純な題材ではなく、株式投資エージェントのような複雑な経済価値判断を要するシーンのはずです。時間を見つけて本来の戦場できちんと測っていきたいです。 おわりに 24 時間 365 日稼働し続ける「眠らない部下」には、電気代という無視できない額の請求書がついてまわります。1 kWh あたり 31 円のこの国で GPU を本気で減価償却しきろうと考えたとき、行き着く先はソーラーパネルを導入することしかないかもしれませんね。 データを手元に、計算を手元に、最後は電力まで手元に。ローカル化の旅は、案外その先まで続いているのかも……。 2026/06/04追記 なんて話をしていたら、Googleが「Gemma 4 12B」をリリースしましたね。今回のモデルは VRAM 16 GBで動く というところがプッシュされているようです。AI開発戦争は秒進分歩。ローカルLLMの 「本当の現在地」 については、ぜひ皆さんのほうで検証いただけますと助かります。 なんて間の悪い！！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @kikuchi.s レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

こんにちは。エンタープライズ第一本部 戦略ソリューション 1 部の英です。 普段はWebアプリやスマホアプリの案件などを担当しています。あと、趣味でAIを勉強しています。 世間ではClaude Codeが幅を利かせるなか、なぜかCodexにこだわり続けている私。 そろそろ流行りに乗らねばと思い、今回はClaude Codeの記事を書いてみます。 しかも、巷ではsuperpowersなんてものが話題になっているらしいじゃないですか。 エンジニアの英知を結集したAI駆動開発のベストプラクティス、superpowers。 これがあれば、Claude Code初心者の私でもプロ並みの開発ができるはずです。 この記事を書き終わっているころには、きっとCodex派からClaude派に寝返っているでしょう。 では、さっそくやっていきましょう。 1.Claude Codeとは 2.superpowersとは 3.Claude Codeの初期セットアップ 4.superpowersのインストール 5.superpowers-brainstorming 6.superpowers-using-git-worktrees 7.superpowers-writing-plans 8.superpowers-subagent-driven-development or executing-plans 9.superpowers-test-driven-development 10.superpowers-requesting-code-review 11.superpowers-finishing-a-development-branch 12. 動作確認 Plan2について さいごに Codexとの比較 開発効率とコスト 採用情報 1.Claude Codeとは Claude Codeは、Anthropic社が提供しているAIコーディングエージェント。 ターミナル上で動作し、コードの生成・修正・調査・テスト実行などを対話形式で進めることができる。 「AIにコードを書いてもらう」だけでなく、開発作業そのものを一緒に進めることができるツール。 2.superpowersとは superpowersは、Claude Codeをよりうまく活用するためのワークフロー集。 ブレスト、計画作成、TDD、コードレビュー依頼など、開発の各フェーズで使える“型”が用意されている。 Claude Codeに任せきりにするのではなく、人間とAIがうまく役割分担するためのベストプラクティス集。 これにより、Vibe CodingやSpec駆動開発の品質の底上げが期待できる。 参考： superpowers ※MITライセンス superpowersは以下のワークフローで構成されています。 要件を整理する 作業環境を分ける 実装計画を立てる テストを書きながら実装する(TDD) レビューする ブランチを仕上げる まず、 brainstorming で実装したい内容を整理します。 いきなりコードを書き始めるのではなく、Claude Codeが質問をしながら、目的・仕様・代替案・懸念点を明確にします。 ここで固めた内容が、後続の設計や実装計画の土台になります。 次に、 using-git-worktrees で作業用の独立した環境を作成します。 新しいブランチとworktreeを用意することで、既存の作業環境を壊さずに実装を進められます。 AIに実装を任せるうえで、安全に試行錯誤できる状態を作る工程です。 その後、 writing-plans で実装計画を作成します。 変更するファイル、実装手順、検証方法を小さなタスクに分解します。 READMEでは、プロジェクト理解が浅いジュニアエンジニアでも進められるくらい明確な計画を作る、と説明されています。 After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste 計画ができたら、 subagent-driven-development または executing-plans で実装を進めます。 前者はタスクごとにサブエージェントを割り当て、仕様準拠とコード品質を確認しながら進める方式です。 後者は計画に沿ってバッチ単位で実行し、人間の確認ポイントを挟みながら進める方式です。 実装中は、 test-driven-development によってTDDの流れが重視されます。 テストを先に書く、まだプロダクトコードがないのでテストが失敗する、テストがグリーン(正常に通過)するように実装を追加していくというRED-GREEN-REFACTORの流れです。 期待する振る舞いを先に定義することで、AIが「それっぽく動くコード」を書いて終わるのではなく、テストで確認可能な形で実装を進められます。 タスクの合間には、 requesting-code-review でコードレビューを行います。 実装が計画に沿っているか、バグや設計上の問題がないかを確認します。 重大な問題がある場合は、次に進む前に修正する流れになります。 最後に、 finishing-a-development-branch で開発ブランチを仕上げます。 テスト結果を確認し、マージするのか、Pull Requestを作るのか、ブランチを残すのか、破棄するのかを選択します。 不要になったworktreeの片付けまで含めて、開発作業を完了させます。 つまりsuperpowersは、 「考える → 分ける → 計画する → テストする → 実装する → レビューする → 仕上げる」 という 堅実な開発プロセスをAIエージェントに守らせるための仕組み です。 READMEにも “The agent checks for relevant skills before any task. Mandatory workflows, not suggestions.” とあるように、強制力を持ったワークフローとして設計されています。 3.Claude Codeの初期セットアップ 社内でClaude Enterpriseのライセンスを貰ったばかりでまっさらな状態。 とりあえず挨拶してトークンを無駄遣いしておきます。 VSCodeにClaude Codeの拡張機能を入れます。 ちなみに、CodexとClaude Codeのインストール数とレビューはこんな感じ。 Claude Codeのほうがシェアも評価も高い現状。 インストールが完了すると、ログイン方法を問われます。 先ほどのClaude Enterpriseのアカウントでログインします。 接続確認が表示されるので、「承認する」を押下します。 認証コードが吐かれたので、VSCodeに戻って貼り付けます。 通りました。何やら可愛らしいキャラクターが浮かんでいます。 挨拶して無駄にトークンを消費しておきましょう。 ちなみに彼は何という名前なんだろうと調べてみたところ、「Clawd(クロード)」というそうです。 Crab(蟹)のキャラクターか。かわいいですね。よろしくね、Clawd。 次はターミナルで使うためのインストール。 Pathを通し、インストール確認。 さあ、初めての起動だ。 ターミナルの色合いを選択します。(Dark mode) ログイン方法を選択します。 認証に成功しました。 読み飛ばす人も多いかもしれませんが、ここにとっても大事なことが書いてあります。 そんなmistakesを極力減らすのがこれから紹介するsuperpowersですね。 今回は初めての利用なので、推奨設定を選択します。 カレントディレクトリに対する権限を聞かれてます。ここは自由に操作していいのでYesを選択します。 セットアップが完了しました。 4.superpowersのインストール 公式のマーケットプレイスからインストールします。 このrepoだけでのインストールを選択します。 superpowersを手に入れました。 有効化します。 5.superpowers-brainstorming さて、準備が整ったのでAIとブレストしてみます。 superpowers「何について議論したいんだい？」 日本語もいけるのだろうか？ ただのToDoアプリじゃつまらないので、組織向けのタスク管理ツールをテーマにしてみます。 日本語で返ってきました。 なるほど、モックを見ながら方針を決めていく方法があるそうです。せっかくなので使ってみます。 brainstorming のスキルが読みたいと言っているので許可します。 ブレストが始まりました。 中規模を選択します。 ToDoタスクの振り方、ユースケースを問われています。全部必要そうなので、そのように回答します。 あとでClaude Codeが教えてくれるのですが、「一斉12人」は「一対多」の誤字とのこと。 タスクのリマインド方法ですが、自動を選択してみます。 通知方法はサービス内にしましょう。 認証はサービス独自を選択します。 デプロイ先はAWSを想定しているのでクラウドを選択します。 タスクの進捗確認をできる人ですが、複数選択可とのことで3つ選択してみます。 スコープが広すぎるようで、MVPを聞かれています。 まあいったん一斉送信の実装から入ってほしいですね。 ※MVP（Minimum Viable Product） これは絶対に聞かれると思っていました。完了の定義です。 ここはサービス上で「対応済み」を押させる仕組みで良いでしょう。 設計の確認が始まりました。 デモアプリでMulti-AZはリッチすぎますが、プロダクト開発に使えるか評価したいので、リッチな構成でいきましょう。 「違和感ないです。」と回答します。 次はデータモデルです。 Assignmentという中間テーブルで人とタスクを紐づけていますね。そしてここでステータス管理もしています。 Notificationで通知レコードを管理する構成になっています。良いと思います。 リマインドは複数回発生する可能性があるため、このテーブルで管理します。 良い設計ですね。自分で設計するにしてもこうすると思います。 兼務とかあるとややこしくなりますが、今回はシンプル構成でいきましょう。 次はユースケースのレビューです。 ちょっと、初期開発では不要な部分があるので省略を依頼します。 次は認証・認可周りの確認です。 ここの実装を削りたいので指示します。 次はエラーハンドリング周りの確認。 次はテスト戦略です。 初期開発としては十分すぎる計画だと思います。 ここまでの内容を設計書にまとめてくれるようです。 設計書の作成が始まりました。 6.superpowers-using-git-worktrees ローカルにgitを入れてもらい、writing-plansに引き継ぎます。 7.superpowers-writing-plans 引継ぎが終わりました。 今回はPlan1とPlan2に分かれ、Plan1でMVPを開発し、Plan2の方でデプロイ周りを計画しているようです。 ちなみに、ここまでの作業をccusageで確認。約$7でした。 $7か...個人利用だと厳しいな...。 8.superpowers-subagent-driven-development or executing-plans 次はこの計画を実行に移してもらいます。 進め方は1つのエージェントで逐次実行するか、サブエージェントを駆使してパラレルに開発するかが選べます。 今回はフルパワーが見たいので、サブエージェントを選択します。 サブエージェントのスキルが読み込まれました。 9.superpowers-test-driven-development こっから、基本的にはYesを叩く作業になるのでスクショは一部割愛します。 (AIエージェントに許可する権限を確認しつつ) Task 0.1が完了しました。ここまで30分くらい。 業務PCにdockerが未インストールだったため、ここで人間側にボールが渡ってきました。 ご丁寧に手順まで記載してくれているので、対応してAIエージェントにボールを戻します。 インストールが完了したので、続きを依頼します。 wslのバージョンが古くてDockerが起動できずに人間に返ってきたので、対応して続きを依頼します。 ローカルでPostgres起動、接続確認まできました。ここまで40分くらいでしょうか。 TDD用の環境セットアップが始まりました。 環境のセットアップが終わったので、ここからサブエージェントを駆使してコーディング部分を進めてもらいます。 サブエージェントでの開発に関するスキルが読み込まれました。 パスワード認証部分の仮実装が終わったようです。 TDDでテストコード→プロダクトコードの順番でコーディングが進んでいることがファイルからもわかります。 テストコードにはハッシュ化、パスの検証の正常系、異常系が書かれてます。 ちょっとテストが少ない気もしますが、あとで伏線回収するのでスルーしてください。 10.superpowers-requesting-code-review 部品の開発のたびに、コードレビューを呼んでいますね。 画像の中央付近にテスト品質に関する記載があります。 先ほどのテストケースはこの観点に通過する品質になっていることがわかります。 Test quality — Does the test verify behavior (not implementation)? Does it cover both happy path and one negative case (wrong password)? Does it avoid mocking the thing being tested? 次は権限部分のTDDが始まりました。 先に今回の3つの権限でのテストケースを作成していることがわかります。 失敗テストの作成、失敗確認、実装、成功確認というRED-GREENのサイクルを繰り返して開発が進んでいきます。 コードレビューで、prisma側の権限とアプリ内での権限で重複管理になるから、この書き方はやめてほしいとレビューで指摘を受けてますね。 そのイシューをもとに実装者が修正に入ってます。 なんだか、チーム開発っぽくなってきましたね。 11.superpowers-finishing-a-development-branch Plan1のPhase1が終わったタイミングで、finishing-a-development-branchのスキルを読ませました。 マイグレーションテストを通してくれました。 12. 動作確認 動作確認方法を聞いて、その通りに起動します。 ログイン画面が開いたのでログインしてみます。 ログインできました。 まだ最小限の機能しかないので、引き続き開発を続けます。 全体でPhase7のうち、まだPhase1の状態です。 Phase2はタスク作成周り。 1時間かからないくらいで、Phase2が完了。 Phase3は通知周りの実装。 Phase4はリマインダー周りの実装。 Phase5はダッシュボード周りの実装。 Phase6はE2Eテストの環境構築。 E2Eを実行したところ、1件passして、2件failedになりました。 結果をコピペして、Claude Codeに返します。 2件passして、1件failedになっていました。 再度、エラーログをClaude Codeに連携して修正を依頼しました。 再実行したろころE2Eにすべて合格しました。 ちなみに、E2Eの1つ目の中身はこんな感じです。 「依頼作成 → 担当者が対応済みにする → 依頼者が進捗を確認する」一連の業務フローをブラウザ上で確認するテストになっています。 2つ目はこんな感じ。 部署管理者向けダッシュボードのE2Eテストです。 「DBを初期化→ユーザーを作成→タスクを直接DBに作成→2人分の割り当てを作成→部署管理者でログイン→ダッシュボードを開く→表示を検証(棚卸、1/2 が見えること)」という流れになっています。 3つ目はこんな感じ。 リマインダー機能のE2Eテストです。 「DBを初期化→ユーザーを作成→タスクを直接DBに作成→担当者への割り当てを作成→リマインダーAPIを実行→担当者でログイン→通知画面を確認」という流れになっています。 E2Eに通過したことを伝えると、Phase7に取り掛かりました。 数時間後、Plan1がすべて完了しました。 ちなみに、ここまでかかったコストは約$98(≒1万5千円)でした。 Plan2について AWSへのデプロイはCodexでも容易にできるので、今回の記事では割愛させていただきます。 そのあたりの権限移譲周りについては 過去の記事 を参照してください。 さいごに Codexとの比較 Codexと比べて計画立てて自律的に走る能力が高い Codexと比べてコストが高い 自走してくれるから1日当たりの作業量が多い 計画を立てることにもトークンを消費する サブエージェントを使うと稀にハングする ハングした際にはctrl+oで状態を確認し、ctrl+cで止めてから、再実行を依頼する必要があった。 さらに、この際にsuperpowersのサイクルから外れることがあった。 この場合、以下のように命令してsuperpowersのフローに強制的に戻してもらう必要があった。 プロンプト：ハングしているから一時停止しました。superpowersのスキルを確認してTDDでの開発を継続してください。 開発効率とコスト ここまで約1～2日間でした。(ほかの作業をしながら裏で動かしただけ) コストも1～2万円程度でした。 BtoC/BtoB案件の一般的な開発ではプロダクトの初期開発にかなりの時間とコストがかかります。(技術的につまることが多々ある) これが大幅に削減できると思うと、人力開発の時代にはもう戻れないなと感じます。 採用情報 先日Xで「JTCでは社内のAI利用が進んでおらず働きにくい」みたいなのが話題になってましたが、弊社はこの数年間で各種AIツールのライセンスや申請周りがかなり整備され、めちゃくちゃ働きやすいです。AIを使って仕事したいSIの方はぜひご検討ください。。 ↓ のスターを押していただけると嬉しいです。励みになります。 最後まで読んでいただき、ありがとうございました。 エンタープライズ第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。 私たちは一緒に働いてくれる仲間を募集しています！ 中途採用-エンタープライズ第一本部 新卒採用-エンタープライズ第一本部 執筆： 英 良治 (@hanabusa.ryoji) レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

こんにちは！クロスイノベーション本部 AIトランスフォーメーションセンターの杉江です。 今回は、電通総研の「OJTリーダー制度」における半年間のOJT期間で、私が配属先で経験したことを紹介したいと思います。 先に公開された、私のOJTリーダーを担当してくださった村本さんの記事とあわせて読んでいただくと、OJTリーダー目線と新人目線で、同じOJT期間をどう捉えていたのかの違いも見えてくるかもしれません。 tech.dentsusoken.com 配属先について 新人教育制度の詳細は OJTリーダー側の振り返り記事 で説明されているので、ここでは私の配属先について軽く触れておきます。 私は新人研修後、AIトランスフォーメーションセンター（AITC）のAIコアソリューショングループに配属されました。概要は以下のとおりです。簡単にまとめると、 生成AIソリューション「Know Narrator（以下、KN）」の開発メンバーとして配属された ということです！ AITCは電通総研の中にあるAIに特化したプロジェクトチームになります。さらにAITCの中でもソリューション系グループ（ソリューションコア・ソリューションアプリ）とコンサルティンググループに分かれており、私と新入社員の方はソリューションコアグループに所属しています。ソリューション系グループでは、エンタープライズ向け生成AIソリューション「Know Narrator」の開発、魅力向上に向けた技術検証等を行っています。 Know Narratorは自社開発を行っているプロダクトになりますので、ソリューション系グループが連携しながら開発をしています。つまり、新入社員の方は開発チームの一員となり、プロダクト開発における様々なスキルを身に着けながら、プロダクトの魅力向上に貢献していくことが大きな目標となっていきます。 配属当初の自分と、半年後の自分 半年で取り組んだことを紹介する前に、配属当初の自分がどのような状態だったのか、そしてOJT期間を半年過ごした後にどう変わったのかを先に紹介したいと思います。 配属当初の自分 まず、配属当初の自分の状態について紹介します。 経歴 情報工学専攻の大学院卒 基本情報技術者試験：合格 わかっていたこと プログラミング ：大学の授業や研究を通じて、プログラミングの経験はある程度あった 不安だったこと クラウド ： AWSやAzure等をほとんど触ったことがない AI : ChatGPTやGitHub Copilotを使ったことがある程度 チーム開発 ： ちゃんと取り組んだのは新人研修が初めて こうして振り返ると、配属当初の自分は開発チームのメンバーとして、戦力になれる状態では全くありませんでした。 ただ、これは特別なことではなく、多くの新卒社員が似たような状態で配属されるのではないかと思います。 配属半年後の自分 半年後には、配属当初に感じていた不安がすべてなくなったわけではありませんが、少なくとも 「何もわからない状態」 からはかなり前に進めたと思います。不安だったポイントも以下のように変わりました。 不安だった点が、半年後にはどう変わったか クラウド ： Azureの資格を二つ取得 し、業務の中でもAzureの画面の簡単な操作ができるようになった。 AI : 生成AIソリューションの機能開発を担い 、普段の開発でもAIを活用している。また、 最新技術を調査してチームに共有 する経験を通して、理解を深めた。 チーム開発 ： 開発チームに本格的に入り、Know Narratorの主要機能の1つを 仕様整理から実装、テストまで一貫して主担当としてかかわり、周囲と連携しながらリリースに貢献できるようになった。 配属当初の自分が抱えていた不安は、半年のOJT期間を通じて、 実際に手を動かしながら少しずつ埋めていくことができました 。 具体的な取り組みとその感想 ここから、どのような取り組みを通じて成長できたかについて時系列で振り返っていきます。 10月〜11月：まずは0から作って学ぶ OJTリーダー側の振り返り記事 では、この時期の取り組みが次のように整理されています。これを踏まえて、自分でも振り返りたいと思います。 【主に取り組んだこと】 Know Narratorを1ユーザーとしていろいろ触って機能の理解を深める OJTリーダーが個別にタスクを指示し、新人はそのタスクを達成するための実装を行う 1からリポジトリを作り、環境を構築し、実装‧テストまで行う実装プロセスはKN開発を踏襲し、タスク分解→実装→テスト→コードレビューの流れで進める 【狙い、身に着けてほしいスキル】 「できた」という感覚を味わっていただくために、完全に0から始めて自力で少しずつ実装し簡単な生成AIアプリを作る KN開発でのお作法をこちらでも導入しながら進めることで、お作法になれるタスクの進め方や困ったときの相談など、OJTリーダーとの会話を通して慣れていただく実際に製品導入が予定されている機能の先駆け検証‧チーム共有を行うことで、チーム‧製品への貢献を感じていただく 共有時にどのように情報を整理すれば伝わるかなどをチーム内で経験する 10月〜11月は、製品開発に直接関わるというより、まずは Know Narratorがどのような製品なのかを知ることと、Know Narratorの開発環境で使われている技術のキャッチアップ を進めることに取り組みました。 まずKnow Narratorという製品を知るために、まずは実際にシステムを触ってみることから始めました。 ここでは、ユーザー目線で押せるボタンを一通り触り、何が起きるかを見たり、裏側でどう処理されているのか気になった点を日報に書いたりしながら進めました。当時は「新人に任せる仕事がないから、やっているのかな？」と思っていた部分もありました。しかし、開発に関わるシステムを理解するために非常に重要な時間だったと、今になって思います。 技術のキャッチアップでは、Gitのリポジトリを1から作り、簡単なAIチャットアプリを作りながら、開発で必要なAIや開発環境の知識、プログラミングのお作法などを学びます。 OJTリーダーから小さなタスクを一つずつもらい、対象の技術をキャッチアップしながら、実装、Pull Requestの作成、レビューという流れで進めました。 基本的にはまず自分なりに進め、その成果物に対してOJTリーダーの村本さんだけでなく、他の開発メンバーからもコメントやアドバイスをいただけたので、タスクを進めるたびに新しい気づきを得ることができました。 下図は実際に作っていたアプリです。 リポジトリを1から作ることのメリットは、リポジトリ内のすべてのコードを自分が把握している状態で進められることにあると感じました。既にプロジェクトとして時間が経っているチームに後から入ると、既存のコードを理解するのに大きな労力がかかります。また、開発環境の構築や設計のように、既に整備されている部分を自分で作る経験も得にくいと思います。 開発チームでは、コードフォーマッターやリンター、GitHubでPull Requestを出したときに動く自動テストやレビューなど、品質を保つための仕組みがいくつも整備されています。こうした仕組みについても、自分で1から構築したことで、のちに開発メンバーとして本格的に入ったときも、 「なんか勝手にいい感じに動いている」ではなく、裏側でどのような仕組みが動いているのかをイメージしやすく なりました。 また、キャッチアップと同時に、製品に今後導入予定だった技術の調査と検証を実施しました。検証では上記チャットアプリに技術を組み込み、そのノウハウをドキュメント化。開発チームに連携しました。 公式ドキュメントの内容をそのまままとめるだけではなく、気になったところを追加で調べたり、実際に動かしたコードを載せたりすることで、初めてチーム内で価値のあるドキュメントにできたと感じています。このとき作成したドキュメントが、その後の開発で他のメンバーの参考になったのは、自分にとってもうれしい経験でした。 この時期にAzureの基礎的な資格も二つ取得しました。とはいえ、資格だけでは業務にほとんど応用できないことを後々感じることが多かったです。来年以降は、作成したチャットアプリをAzure上でデプロイしてみてもいいかなとも思います。 11月〜1月：KN開発に入って感じた壁と、慣れるまで 11月の後半から1月について取り組んだことは以下のとおりです。（ OJTリーダー側の振り返り記事 から引用） 【主に取り組んだこと】 Know Narratorの開発環境を構築、環境構築手順資料の改善を行う Know Narratorでリリース前に行っているシナリオテスト行う軽微なバグの修正作業や、コードのリファクタリングを行う 社内で開催されていたAI Coding学習会に参加する 【狙い、身に着けてほしいスキル】 環境構築をしながら既存の環境構築資料をどう改善すればよりわかりやすくなるか考えていただく Know Narrator開発におけるタスクをこなしながら、チーム開発‧チームメンバーとのコミュニケーションに慣れる Know Narratorのコードベースに対する理解を深める 11月からは本格的に開発チームの一員として、タスクを進めることになりました。 まずはKnow Narratorを開発するための 環境構築 をしました。村本さんから、「わかりづらいドキュメントだなと不満に感じたら、次から入ってくる人も感じるところなのでガンガン直してくれたら嬉しい」みたいなことをよく言われていたので、実際にいくつか修正したり、自分で新しくドキュメントを作ったりもしました。 実際、二年目の先輩が昨年環境構築した際に残していたドキュメントに大変助けられたりしたので、 ドキュメントを残すことの重要性 や、足りなかったら自分で直すという意識づけがここで徹底できたかなと思います。 環境構築が終わった後に最初の大きなタスクとなったのが、 リファクタリング でした。 実は最初に取り組むはずだった機能開発を進めるにあたり、コードベース上にいくつかの課題があったのです。この課題を解決しないことには実装作業が進められないと判断され、リファクタリングをやってみましょうという流れになりました。 初めて本格的にやるタスクがリファクタリングということで、進め方など村本さんにかなりサポートはしてもらったものの、ここでだいぶ苦戦しました。 リファクタリングは外から見た動作を変えずに内部のソースコードを整理することなので、リファクタリングの影響範囲のコードがどう動いていて、どこに依存関係があるかを理解しないと前に進めません。製品の既存コードを理解するところが特に大変でした。 最初はかなり時間がかかりましたが、タスクを進めるうちに次第に理解するスピードが速くなり、なんとか進めていけました。結局、量を読むことが鍵でした（笑）。加えて、既存のコードベースが開発・保守しやすいようにきれいな階層で分けられていたため、それぞれの役割を理解し、処理の流れをイメージできるようになったことも大きかったです。 コードベースの設計思想については村本さんと1on1の時間で一度しっかりコミュニケーションをとって、自分の認識のズレや既存の設計でモヤモヤしていた点を解消できたのが大きかったです。 この経験から、 コードを読むだけでなく、人と話すことの重要性 を学びました。 また、この時期からリリース前の シナリオテスト も担当するようになりました。 シナリオテストはKnow Narratorの毎月のアップデート前に、意図する動作になっているかをチェックするために実際に触って確認するテストのことです。 シナリオテスト自体は特別面白い作業ではないですが、10月にKnow Narratorを触りまくったときと同じように、製品に対する理解が進みました。また、これまでのタスクではOJTリーダーの村本さんとのコミュニケーションが中心でしたが、テストを進める中で、テストを作成したメンバーや機能を開発したメンバーとやり取りする機会が増えました。パートナー会社の方や開発チームの他メンバーとも関わることができ、連携の幅を広げる良い機会になりました。 2月〜3月：自分が実装した機能のリリースを経験する 2-3月に取り組んだことは以下のとおりです。（ OJTリーダー側の振り返り記事 から引用） 【主に取り組んだこと】 継続してKnow Narrator開発の様々なタスクを担う Know Narratorとして大きなアップデート要素となりえる主要機能を作り切る 【狙い、身に着けてほしいスキル】 自分が実装した機能が製品に乗る喜びを味わっていただく大きな機能開発を通して、設計や実装、テストはもちろん、自身のタスク整理やコミュニケーションのリードを経験してもらうプロダクトオーナーやビジネスオーナーに対して、機能の開発状況や仕様について説明する経験をしていただく 2月・3月で新しく開発タスクとして行ったことは大きく分けて2つです。 Know Narratorで採用予定だった新技術のキャッチアップと動作確認 3月末のアップデートの機能の一つを仕様整理から開発・テストまでを一貫して行い、KNのアップデートに自分が作った機能を載せる まず一つ目の技術調査についてです。 11月でもすでに技術調査を行いましたが、2月の技術調査では、単に調査して手元で動かすだけでなく、Know Narratorのプロジェクト上でテストコードを実装し、 Know Narratorの環境でも実際に動作することを確認するまで をゴールとした検証を行いました。 手元で簡単に動かすのとは違って、既存のプロダクトコードを見ながら、使えるところは共通化して実装するところに、より難しさを感じました。また同時にIDEのデバッグモードを活用したデバッグについても学ぶことができました。 二つ目の機能開発についてです。 ここで感じたことは、二つあります。 一つ目は、機能の仕様を考えることは前提を考えるのとセットであることです。 最初に仕様を決める際に、仕様について開発チームの先輩に相談したところ、この機能が使われるときの前提条件があるはずだから、それを元に判断すれば良いというコメントをもらいました。 二つ目は、タスクを整理することの難しさです。 今までは割り当てられたタスクをこなす側であることがメインだった一方で、このタイミングでは、タスクを整理して作る側に回ることを経験しました。この点は村本さんにかなりサポートをしてもらって、タスクの切り分けの単位や、画面デザイン作成の依頼、一部実装のパートナー会社の方への依頼なども一緒に進めてもらえました。 一人では開発が進まず、先回りしてコミュニケーションを取りながら開発を進めることが重要だと感じました。 タスクの進め方には課題が多くありましたが、自分の開発した機能をOJT期間にリリースするところまで持っていけたので、自信にもつながりました。 チームとのコミュニケーション ここでは、OJT期間中に感じたチームとのコミュニケーションについて振り返ってみます。 開発部屋 私が所属するAITCの開発チームは、リモートワークがメインで、基本的に一日中 開発部屋 と呼ばれるTeamsのオンライン会議に入って開発を進めています。配属直後は、メンバー全員がいる場で声を出して質問することに少しためらいがありました。 ただ、慣れてくると、開発部屋にいることでどのメンバーが会話できるかがすぐにわかったり、会話を聞いていた他の先輩がプラスアルファでコメントをくれたりして、とても仕事のしやすい環境だと感じるようになりました。 開発部屋については別記事でも紹介されているので、気になる方は見てみてください。 tech.dentsusoken.com 1on1 10月の配属直後には、開発チームのメンバーと基本的に 対面で1on1 をする機会をいただきました。オンライン中心だとコミュニケーションが少しドライに感じることもありましたが、対面で話すことで人となりがわかり、とてもよかったです。 また、OJTリーダーの村本さんとは 隔週で1on1 をしていて、 日々の雑談から仕事の進め方で迷っているところの相談 までしていただき、とても助かりました。 新人用Teamsチャネル 10月から12月は、新人が基本的にTeamsの一つのチャネルを見るだけで必要な情報を得られるように、新人用チャネルを用意してもらっていました。 ここには、業務でよく参照するサイトのリンクや事務的な連絡、TODOリスト、気になることを質問できるスレッドなどが一つのチャネルにまとまっていて、 とりあえずこのチャネルを見れば大丈夫 という状態になっていました。 よく「〇〇サイトの\~~というページを開いてください」的なことを指示されると、どこを見ればよいか迷うこともありますが、このチャネルのおかげで「どうやって行くんだっけ」と探す手間はほぼなかったです。 同チャネルで日報の作成も行っていました。日報はYWTP形式（やったこと・わかったこと・次やること・問題）で書いていましたが、自分のW（わかったこと）やP（問題）に対して、OJTリーダー以外の方もフィードバックとアドバイスをいただけて、非常に助かりました。 日報はOJT期間が終わった後も、開発チーム内で同じ形式で実施していて、日々メンバーが考えていることや発見がわかったり、アドバイスをいただけたりして大変ありがたいです。 OJTリーダーとのやり取り 村本さんは実は関西支社の方で、東京にいる私とはオンラインでのコミュニケーションがメインでした。最初は少し驚きましたが、オンラインでも日々のチャットや1on1等でしっかりコミュニケーションを取っていただいたので、不満は全くありませんでした。やり方次第でどうにでもなるんだなと感じました。 10月から12月までは毎日村本さんと朝会をしていて、日報をもとに進捗確認やフィードバック、つまずいているところの相談等をしていました。 タスクを進める中で出る質問は開発部屋で行う形にしていました。ただ、村本さんが忙しくて開発部屋にいらっしゃらないことが多い時期は、進め方に少し苦労しました。他のメンバーの方は私のタスクを詳細に把握していないケースがあったため、手が止まってしまう時間もありました。 今振り返ると、自分がもっと他の先輩にも頼るようにコミュニケーションを取ればよかったと感じます。そのうえで、特定の一人に頼りきりにならない体制や、気軽に相談できる相手を増やしておくことも、受け入れをやりやすくするうえで大事だと思いました。 半年を振り返ってみて OJT期間半年を通して、開発チームのお荷物と勝手に感じてしまうような状態からは脱却できたかなと思っています。半年間で自分でも成長できたという実感があります。 OJT期間で私が恵まれていたと感じることは、 とにかくゆっくり自分が納得するまでやっていい というスタンスで見守ってもらえたことです。特に今は生成AIが発達しているので、理解せずとも形にできてしまう部分はあるのですが、自分の成長を優先してもらえたことで、技術力の向上につながり、精神的にもいい意味で楽な状態で半年間過ごすことができました。 OJTリーダー側の視点を受けて ここで、 OJTリーダー側 からはどう見えていたのかも振り返ります。 『「新人さん」ではなく「新しいメンバー」をチームで受け入れる』ことが、私のOJT期間のテーマ になっていたようです。 特に配属後の2〜3か月は、このスタンスを強く感じていました。オンボーディング中は、暗黙知を知らない立場だからこそ気づける点を踏まえて、チーム内ドキュメントの整備をしっかり任せてもらったり、やりづらいところを丁寧に聞いていただいたりしました。 そうしたやり取りを通じて、新人・ベテランに関わらず、これから新しく開発チームに加わる人に向けたオンボーディングの改善につなげようという意識を感じました。自分自身も、 オンボーディングの改善に貢献するという意味で責任感を持って取り組む ことができたので、オンボーディング中に感じるやりづらさも前向きに捉えられたような気がします。 こういった環境や自分の成長につながるタスクを用意してくださった村本さんはじめAITCの先輩方に感謝し、今後新しく入ってくるメンバーに対しては、自分が直近でオンボーディングを経験したメンバーとして力になりたいと考えています。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sugie.naoki レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

1. はじめに はじめまして！電通総研の武田嵩史（たかふみ）と申します。テックブログを執筆するのが初めてで怯えながらの投稿ですが、全2回に渡り本テーマについて発信できればと思います。簡単に私の自己紹介をしてから本内容に移りたいと思います。 自己紹介 改めまして武田嵩史と申します。普段はクラウドを用いたシステム開発や運用のプロジェクト・マネージャーをしております。 その中でも最近ではクラウドHPCの基盤を構築することが多く、様々なクラウドベンダー様とお仕事をさせていただいております。 ”クラウドHPC”？なんじゃそりゃ？という方は弊社が公開している以下記事をご覧いただければと思います！ SDGsの達成にも貢献！？クラウドHPCについてもう一度考えてみる 電通総研のクラウドHPCサービスがもたらす革新とメリット 扱うクラウドはAWS, Azure, OCIの3つが主でして、それぞれのクラウドプロバイダーの強み・特徴を活かして最適な環境をお客様に提供することを得意としております。 モチベーション さて、そんな私がクラウドHPCの中でも最近特に注目しているのが、AWSの "hpc8a" インスタンスです。 AMD社の最新プロセッサであるTurin（EPYC 9R45）を搭載したインスタンスタイプでして、 ap-northeast-1（東京） リージョンで利用ができることが1つの特徴です。 このインスタンス、AWS公式のページを引用すると以下のパフォーマンスを発揮するとのこと。 前世代の Hpc7a インスタンスよりも 最大 40% 優れたパフォーマンス、42% 広いメモリ帯域幅、最大 25% 優れた料金パフォーマンス を実現します。 （引用元） 第 5 世代 AMD EPYC プロセッサを搭載した Amazon EC2 Hpc8a インスタンスの一般提供開始 HPCワークロードの特徴上、解析データサイズも大きかったり、多くのI/Oが発生したりするので、データとコンピューティングリソースは可能な限り近い場所に置く方がパフォーマンスを発揮できます。そのため、日本のお客様は日本で利用できる高性能なマシンはあればあるだけ嬉しいので、このインスタンスタイプに私自身もとても興味があり、実力はどんなものかと調査すべく今回のベンチマーク実施に至りました。 本題 本記事は以下の流れとなっております。 目次 はじめに ←終了 ベンチマーク概要 Ansys Fluentベンチマーク結果 Cradle MSC scFLOWベンチマーク結果 おわりに（次回予告） 2. ベンチマーク概要 2.1 ベンチマークに利用したインスタンスタイプ ベンチマークと言ってもhpc8aだけで解析実行しても仕方ありません。ということで、今回は以下のEC2インスタンスタイプを選定しベンチマークを実施しました。 Instance type Spec Cost $ (instance/h) Cost $ (core/h) hpc6id.32xlarge (Intel) CPU：Intel Xeon Ice Lake 64cores 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：50 Gbps EFA $9.85 $0.05 hpc7a.96xlarge (AMD) CPU：AMD EPYC 9R14 Genoa 192 cores Memory：768GB NIC：300 Gbps EFA $7.20 $0.04 m8a.48xlarge (AMD) CPU：AMD EPYC 9R45 Turin 192 cores Memory：768GB NIC：75 Gbps EFA $11.69 $0.06 c8a.48xlarge (AMD) CPU：AMD EPYC 9R45 Turin 192 cores Memory：384GB NIC：75 Gbps EFA $10.35 $0.06 hpc8a.48xlarge (AMD) CPU：AMD EPYC 9R45 Turin 192 cores Memory：768GB NIC：300 Gbps EFA $7.92 $0.04 c8g.48xlarge (AWS) CPU：AWS Graviton4 192 cores Memory：384GB NIC：50 Gbps EFA $7.63 $0.04 ※Costはオハイオリージョンでの単価です。 ※Cost $ (core/h), Cost $ (instance/h)においては小数点3桁を四捨五入した小数点以下2桁で表記しております。 ※一部ベンチマークについては結果がないインスタンスタイプもございます。 選定の基準としては3つの観点で行いました。 ” 1. 会社 " CPUの製造元として代表的なIntel, AMDを選定。また、AWSも独自でプロセッサを開発しているので、Gravitonもノミネートしました。 " 2. 世代 " 各CPUの世代が上がると性能も向上するのか、どの程度向上するのか、という指標をみるために複数世代を選定しました。 " 3. インスタンスの用途 " AWSは同じCPUを搭載していても、ワークロードによって最適化されたインスタンスタイプを準備しています。基本的にはコンピューティング最適化インスタンス（cシリーズ）とHPC特化インスタンス（hpcシリーズ）を選定していますが、メモリ最適化（rシリーズ）、汎用（mシリーズ）も選定しているものもあります。 2.2 ベンチマーク実施内容 ここではどのような条件、ソルバでベンチマークを行ったかをご説明いたします。 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 この中で第1回となる今回は Ansys Fluent と Cradle MSC scFLOW のベンチマーク結果を皆様に共有いたします！ 2.2.2 ベンチマーク実施環境情報 ベンチマークを実施した環境情報は以下のとおりです。 項目 内容 OS Red Hat Enterprise Linux 8.10 ストレージ Amazon FSx for Lustre （SSD / 250 MB/s-TiB ） *4.8 TiB ネットワーク EFA 有効化 ジョブスケジューラー Slurm MPI Intel MPI 2021.13 MPI （Arm プロセッサ利用時） Open MPI 4.1.7 また、これらの環境の準備にはAWS ParallelClusterを利用しており大変便利なサービスでしたので、こちらも別途ご紹介できればと思います。 （参考） AWS ParallelCluster 2.2.3 ベンチマーク評価項目 ベンチマークの評価項目は以下の3つの指標で評価を行いました。 1．実行時間 各ソルバーの実行時間を秒単位で計測。 2．コスト 各ベンチマークジョブを完走するのに必要となるインスタンスの費用を計算。ここでは起動/停止にかかる費用やデータの保管費用、通信にかかる費用は含んでおらず、あくまでベンチマークジョブを完走するのにかかったコンピューティングリソースのみの費用を算出しています。 3．コストパフォーマンス 「計算速度が速くても値段が高いと簡単には利用できない。」というのが実情だと思いますので、今回はコストパフォーマンスという指標も準備しました。コストパフォーマンスは以下式で定義します。 今回は簡単のために、Genoaプロセッサを搭載したコンピューティング最適化インスタンスタイプ "c7a.48xlarge"を"1.0"として正規化したスコアで評価しました。 3. Ansys Fluentベンチマーク結果 それではAnsys Fluentのベンチマーク結果がこちらです。Ansys Fluentでは256並列から2048並列までの並列数で実施しました。 3.1 実行時間 ソルバー実行の経過時間比較 同一並列解析数の場合、全ての場合でTurin (m8a, hpc8a) のインスタンス性能が良い結果となりました。 前世代とのパフォーマンス比較 全並列数で3割程度のパフォーマンス改善がみられました。AWS公式によると、 最大40%の優れたパフォーマンス とのことだったので、今回の結果はそれに近い結果が得られました。 Gravitonの計算スケール c8g (Graviton4) については、並列数が増加するにつれ、他インスタンスタイプとの経過時間の差は縮小傾向にあり、大規模並列計算において計算時間のスケールメリットが出ることが確認できました。 3.2 コスト コスト比較 hpc8aが全ての並列数で一番コストが低い結果でした。 Ansys Fluentの今回のベンチマークモデルにおいては512並列が一番コストに優れた並列数となりました。 前世代とのコスト比較 全並列数で2割程度のコスト改善がみられました。AWS公式によると、 最大 25% 優れた料金パフォーマンス とのことだったので、こちらも公式に近い結果が得られました。 3.3 コストパフォーマンス コストパフォーマンス比較 hpc8aが一番コストパフォーマンスに優れた結果になりました。 同CPUスペックで比較するとHPCインスタンスはコストパフォーマンスが高い結果がみられます。 c8g (Graviton4) は2048並列になると、c7aのコストパフォーマンスを上回る結果になりました。 以上がAnsys Fluentのベンチマーク結果となりますが、いかがでしたか。 実行時間・コスト・コストパフォーマンス全てにおいてhpc8aが良いパフォーマンスを示していたことがみてとれたのではないでしょうか。 4. MSC scFLOWベンチマーク結果 続いてはCradle MSC scFLOWのベンチマーク結果です。scFLOWでは128並列から1024並列までの並列数で実施しました。 scFLOWにおいては一部実施できていないインスタンスタイプがあることご了承ください。 4.1 実行時間 ソルバー実行の経過時間比較 同一並列解析数の場合、全ての場合でhpc8aの性能が良い結果となりました。 前世代とのパフォーマンス比較 こちらもAnsys Fluentと同様、全並列数で3割程度のパフォーマンス改善がみられました。 4.2 コスト コスト比較 hpc8aが全ての並列数で一番コストが低い結果でした。 前世代とのコスト比較 こちらもAnsys Fluentと同様、全並列数で2割程度のコスト改善がみられました。 4.3 コストパフォーマンス コストパフォーマンス比較 上記の結果からも分かるとおり、hpc8aが一番コストパフォーマンスに優れた結果になりました。 以上、scFLOWのベンチマーク結果でしたが、大きな方向性としてはAnsys Fluentと変わらず、実行時間・コスト・コストパフォーマンス全てにおいてhpc8aが良いパフォーマンスを残していました。 5. おわりに（次回予告） というところで今回はAnsys FluentとCradle MSC scFLOWにおけるhpc8aのベンチマーク結果をご紹介いたしました。 次回は衝突系ソルバのAnsys LS-DYNAと流体系ソルバSiemens STAR-CCM+のベンチマーク結果もご紹介いたしますので、そちらもお楽しみにお待ちいただけますと幸いです！ 末筆になりましたが、本ベンチマーク実施にあたりご協力いただきました各社様、ご関係者の皆様に厚く御礼申し上げます。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @takeda.takafumi レビュー： @kobayashi.hinami （ Shodo で執筆されました ）

はい、こんにちはー！クロスイノベーション本部 サイバーセキュリティテクノロジーセンターの福山です。 昨年あたりから、ソフトウェア脆弱性報告件数の増加やサプライチェーン攻撃のニュースが目立つようになりました。 そこで今回は脆弱性管理とソフトウェアサプライチェーンの現状を把握すべく、関連テーマにフォーカスしたセキュリティカンファレンス「VulnCon」にバーチャル参加しましたので、本稿にレポートとしてまとめます。 VulnConとは 1. NIST's National Vulnerability Database Update and the Vulnerability Enrichment Ecosystem 2. Vulnrichment Playground 3. Supply Chains and Malware Campaigns: Is CVE the Right Way to Name the Game? 4. How to Answer "What's Affected?" in Open Source 5. Identifying Exploited and Likely-to-Be-Exploited Vulnerabilities 6. Taming the Scanner Storm: How VEX Brings Context to Vulnerability Data 7. Contextual SBOMs: Unlocking Precise Vulnerability Management with Build-Time Content Intelligence 8. Lessons From NPM's Dark Side: Preventing the Next Shai-Hulud まとめ VulnConとは VulnConとはCVEプログラムやFIRSTが中心となって主催する「脆弱性管理に特化した国際カンファレンス」です。 第1回開催は2024年と比較的新しいカンファレンスであり、今年は米国アリゾナ州スコッツデールで開催されました。 https://www.first.org/conference/vulncon26/ VulnConは、脆弱性管理とサイバーセキュリティ分野の専門家が一堂に会し、意見交換などを行い、具体的な成果の創出を目指す場となっています。 今回、VulnCon 2026（現地時間：2026年4月13日～4月16日開催）をリモートで視聴（参加費用 $100）し、筆者が注目した8つのセッションを紹介します。 本記事では各セッション内容をもとに、脆弱性管理およびサプライチェーンセキュリティの観点から重要なポイントを整理しました。 なお、本記事は講演者の発言内容に基づく書き起こしであり、内容は「TLP:CLEAR」のみです。 1. NIST's National Vulnerability Database Update and the Vulnerability Enrichment Ecosystem 発表：NIST NVD NVDの役割 CVEに対してNVDは追加メタデータ（CPE・CVSS・CWE・参照タグ）を提供する「バウンダリーオブジェクト」として機能 CNAは2016年以降独自公開が可能になり、現在502のCNAが存在 スケールの問題：NVDが直面する現状 CVEの増加数が過去最大レベルに達しており、現行の手動プロセスでは追いつかない CPE割り当てに分析時間の半分以上を消費（LLMプロジェクトやGitHubベースのソフトウェアの急増が負荷を増大） 大規模な未処理バックログが蓄積 NVDの新しい優先度付けアプローチ（リスクベースへの転換） CISA KEVリスト掲載CVE：1営業日以内にエンリッチ（付加情報の付与） 米国連邦政府ソフトウェアに関連するCVE 大統領令14208号で定義されたクリティカルソフトウェアのCVE リクエストベースでの対応も受け付け（対応は可能な範囲で実施） CVSSスコアの方針変更 既にスコアを持つCVEには重複スコアを付与しない（Gap Fillingの正式化） アナリストが矛盾を発見した場合は再評価の可能性あり ※Gap Filling：2025年から暫定導入され、CNAから提出されたCVSSおよびCWEデータを再検証せずに、一時的に受け入れる方針のこと バックログの整理 「deferred」ステータスを「not scheduled」に改名 2026年3月1日以前の古いバックログは原則「not scheduled」に移行 修正されたCVEの再エンリッチは原則行わず（リクエストがあれば対応） 自動化への取り組み LLM/AIを活用した分析自動化を小チームで研究中：完成次第オープンソースとして公開予定 RPAによる反復作業の自動化も並行して検討 CPE管理のフェデレーション化（CNAや作業グループと協議中） 2. Vulnrichment Playground 発表： CISA、Tharros Labs Vulnrichmentとは CISAが連邦政府機関（FCEB）や重要インフラ保護のために行っている脆弱性分析を広く公開する取り組み CVEのADP（Authorized Data Publisher）コンテナとして提供、GitHubリポジトリからも取得可能 毎年約2,000件以上のCVD（協調的脆弱性開示）ケースを処理する中で得た大規模な分析知見が元になっている Vulnrichmentが提供するデータ SSVC（Stakeholder Specific Vulnerability Categorization）：全新規CVEにスコアリング KEVフラグ：既知の脆弱性悪用カタログへの掲載有無 CVSS・CWE：CNA未提供分のバックフィル（CNAが既に提供している場合は上書きしない） 参照タグ：パッチ・アドバイザリ等の分類 2年目の最大の変化：CPEの廃止 当初CPEの付与も実験的に行っていたが、分析時間の2/3をCPE作成に費やしていることが判明 利用者からの「CPEよりSSVC・KEV・CWEのカバレッジを広げてほしい」という声を受けて廃止 CPE廃止によってリソースを再配分し、全新規CVEへの完全エンリッチメントが可能になった 「Playground」の本質：本番環境での実験 KEVは拘束力のある運用指令（BOD）に紐づいており変更コストが高い。Vulnrichmentは低リスクで実験できる場として設計されている 「追加するだけでなく、やめることも重要」という姿勢：CPE廃止がその実践例 Linuxカーネルから「上流カーネル脆弱性のCVSSスコアリングをやめてほしい」という要望（GitHub Issue #262）も公開の場で議論中 Pandoc CVEを使った実践例（CVE記録がどう変化するか） 当初：記述不明確、影響範囲（affected）が「N/A」、誤った参照リンク Vulnrichmentが同日中にCVSS・SSVCを追加 数ヶ月後：参照を修正、SSVCの技術的影響を誤入力→後日修正 実験的介入：CISAが直接Pandocの開発者と議論・検証を行ったうえで書き直す（通常スコープ外） 今後の実験候補：CVE間の関係性の表現 現在は記述文の最終行に「他のCVEとの関連」を自然言語で書くしかない 「CVE同士の関係性を機械可読な形で表現できないか」をVulnrichmentで実験したい（スキーマ変更の前段として） Pandocの例：外部ツールの呼び出し時に別のSSRF脆弱性が発生→関係性が人間にはわかるが機械には処理できない Supplier ADP（SADP）パイロットへの言及 CNA自身が「自社製品でこのCVEは影響なし」というVEX的な情報をADPコンテナとして追記できる仕組みのパイロット 例：Pandocを組み込んだ自社Webアプリが --sandbox など安全な方法でPandocを呼び出しており影響を受けない場合、（提供元がCNAであれば）その旨をADPコンテナとして「影響なし」と追記できる。 参考： https://github.com/CVEProject/sadp-pilot Vulnrichmentのデータ品質・透明性について CVEプログラムのレコード・NVD・Vulnrichmentの3つを信頼性で順位付けするのは難しい 「GitHub上で問題提起→議論→修正」という透明なプロセスが品質の担保 CVSSだけで脆弱性を優先度付けするのは不十分であり、SSVCのようなコンテキスト情報との組み合わせが重要 3. Supply Chains and Malware Campaigns: Is CVE the Right Way to Name the Game? パネルディスカッション： Telos Labs、VulnCheck、HeroDevs、GitHub 議論の前提 CVE CNA Rules 4.1.8 / 4.1.9：一般的な目的で故意に作成された悪意のあるコードはCVE対象外。ただし、トロイの木馬、バックドア、または類似のサプライチェーンの侵害など、悪意のある形に改変された製品は、脆弱性であると判断される可能性がある。 OSVやOpenSSFのmalicious-packagesリポジトリなど代替はあるが、エコシステム全体での標準化や運用の成熟はまだ発展途上 ケース1：XZ Utils（CVE-2024-3094）—バックドア埋め込み Red Hatがバックドアを悪意ある改変済み正規コードとしてCVEを発行 CVEがあったことで、既存の脆弱性管理パイプラインがすぐに対応できた CVEなしでは「どのXZ Utilsの問題か」の識別子がなく、情報伝達が混乱していた可能性 ケース2：tj-actions（CVE-2025-30066）—GitHubアクションの侵害 メンテナーのアカウントがロックアウトされた状態でMITREがCVEを発行 メンテナーが機能停止しても、他のCNA（この例ではMITRE）がCVE発行で通知を前に進められる可能性が示された CVEがあったことで既存ワークフローへの統合が即座に可能 ケース3：Shai-Hulud—npmワームキャンペーン npmのマルウェア削除処理がCVEなしで機能し、GHSAが公開されnpm auditで警告 CVEを使わなくても npm エコシステム（GHSA/npm audit）が機能した ただしCVEシステムにはキャンペーン全体を関連付けるメカニズムが存在しない（記述に書くしかない） ケース4：Trivy侵害（CVE-2026-33634） GitHubがTrivy向けCVEを発行、下流のLightLLMとTelnyxは個別アドバイザリを取得 パッケージマネージャーをまたがる侵害（Go＋PyPI）でのCVE運用の課題を浮き彫りに CVEが最善の方法か？ 「CVEは25年前の設計思想で動いており、今でも機能している。だが完璧ではない」 キャンペーン全体を一つのIDで追跡したい場合と、個別パッケージごとにIDが必要な場合は矛盾する CVEの増発は対応チームの負荷増大を招く（10件のCVEは1件の10倍の事務作業） 「IDが多すぎることは問題ではないが、それらを関連付けられないことが問題」（現行CVEにそのメカニズムなし） 4. How to Answer "What's Affected?" in Open Source 発表： Google CVEプログラムの課題 1999年は321件 → 現在は10分に1件ペース 構造化されていないテキストが多く、自動マッチングが困難 NVDのCPE付与の遅延により手動処理が必要な状況が続いている OSV（Open Source Vulnerability）スキーマの設計思想 機械可読な形式でオープンソースの脆弱性を記述 introduced （脆弱性の混入時点）・ fixed （修正が入った時点）・ last_affected （影響を受ける最終点）イベントで範囲を定義 OSVの設計がCVE5.0スキーマにおけるバージョン範囲導入に影響した バージョン範囲の複雑さ（LTSブランチ問題） 「1.xで導入→2.2.8で修正→3.0で再導入」のような複数ブランチは単純な線形バージョンでは表現しづらい コミットの差分（diff）をハッシュ化した patch-id を使うことで、チェリーピックされた修正を自動検出できる Gitは本質的な順序関係を持つため、エコシステム固有のバージョン比較ロジックに頼らずに済む 「影響あり」判定のルール 導入コミットから現在のコミットへ、修正コミットを経由しないパスが存在する場合に影響あり マージコミットの扱い：修正ブランチ取り込みでも履歴次第で安全性が変わる。判断には“introduced→当該commit”の経路にfixedを含むか、曖昧なら影響あり寄りに倒す。 introduced: 0 （最初のバージョンから脆弱）の際、Gitの複数ルート（subtreeなど）への対処も明示 データソースの種類 エコシステム直接提供（crates.io、GoなどはOSVフォーマットで直接提供、関数レベルの情報も含む） GitHub Security Advisory（GHSA）経由でMaven・npmの情報を補完 CVE/NVDからの変換：バージョンタグとGitコミットを照合して範囲を推定（ただし修正コミットではなくリリースコミットを辿りがちで限界もある） ここから学べること CNAとしてGitコミットハッシュでの脆弱性レポート提供を強く推奨 ツール（VEX・到達可能性解析・静的解析）と組み合わせて「自分のプロジェクトで実際に影響を受けるか」をさらに絞り込める 5. Identifying Exploited and Likely-to-Be-Exploited Vulnerabilities 発表： VulnCheck VulnCheckのCNA活動の3本柱 Report of Vulnerability Service：外部研究者から脆弱性報告を受け付け、CVE発行まで無償でサポート 脆弱性研究・CVD調整：サードパーティとの調整、監査、CVEアサイン Initial Accessチーム：エクスプロイト開発、検知アーティファクト作成（実際に脆弱なコンテナを本番インターネットに公開して攻撃トラフィックを確認） VulnCheck独自KEVの定義と実態 「公開情報として悪用報告があるもの」または「VulnCheckが観測したもの」すべてをKEVとして扱う（CISAより広い定義） 2025年の悪用確認済み脆弱性のうち約28%が開示日当日以前に悪用証拠あり AIの普及によりこのタイムラインがさらに短縮される懸念 CVE未割当の悪用脆弱性の発見：Shadow Serverとの連携 Shadow Serverのシンクホール（悪用検知シグネチャ）を分析→CVEが存在しない状態で長年悪用されていた脆弱性を約50件発見、CVEアサイン 実例：2016年から公開されていたD-LinkのDSLモデムの脆弱性→2025年まで未割当→CVEアサイン後にCISA KEVへ掲載 「CVEがない＝リスクがない」ではなく、単に見えていないだけ Metasploitモジュールの監査 Metasploitに存在するエクスプロイトモジュールとCVEの紐付けを全件監査 数百件のモジュールにCVEが未割当→うち約200件はCNA管轄内でCVEアサインが可能 Moore's Lawの進化版：「カジュアルな攻撃者の能力向上速度≒AIの進化速度」になりつつある BlackHat/Bostonのチャットログ例：脅威アクターがMetasploitをインストールし多数のモジュールを活用 製品セキュリティアドバイザリの活用 Microsoft MSRCのような機械可読フォーマットで悪用インジケータを提供するベンダーが理想 実例：Notepad++が悪用→サプライチェーン侵害→VulnCheckがDIBSプロセスで調整しCVEアサイン→CISA KEVへ掲載 DIBSプロセス：重複CVE発行を防ぐ協調メカニズム CNAが集まり、クリティカルな脆弱性に対して「誰がCVEを発行するか」を短期間で合意する非公式プロセス CVE重複発行リスクを減らしながら、対応速度を確保する リポジトリは公開されており参加可能 研究者コミュニティとの関係構築が重要 Project Discoveryなど、繰り返し脆弱性を報告する研究者コミュニティとの信頼関係を構築→深夜にLinkedIn経由でゼロデイ報告が届く Versa Connectの認証バイパス脆弱性：報告当夜にCVEを発行し、翌日にはShadow ServerおよびSibolが実運用環境での悪用を確認→CISA KEV掲載 脆弱性の悪用に関する初期情報は、研究者コミュニティやフォーラム、Discordなどに常駐する「perpetually online groups」によって最初にサーフェスすることが多く、そうしたシグナルをいかに早くキャッチできるかがカギになる 研究者クレジットの重要性 VulnCheckのInitial Accessチームの研究者（Kale）に加え、外部の脆弱性研究チームであるwatchTowr Labs、Code Whiteが同一の脆弱性をほぼ同時に発見する「researcher collision」が発生 全報告者に適切なクレジットを付与することが信頼を構築するうえで重要 ベンダーはアドバイザリとCVEレコード両方にクレジットを記載すべき AIによる影響（Q&Aより） 高スキル研究者が使えば高品質な脆弱性報告の大量提出が可能に スキルの低い報告者からの「スロップ（雑な報告）」も増加 脅威アクターはまだ古い枯れた脆弱性を多用しており、AIによる新規開発加速の実害はまだ計測困難だが、注視中 6. Taming the Scanner Storm: How VEX Brings Context to Vulnerability Data 発表： NVIDIA 前置き この発表はスキャナーから得られる脆弱性データをどう扱うかという話 今回は特にコンテナイメージにフォーカス 一部のイメージを対象に始めたプロジェクトで、その後すべてのコンテナイメージにVEXを適用できるようになった ※VEXとは： https://www.vuls.biz/blog/articles/20241105a#Vulnerability-Exploitability-eXchange-VEX （上記FutureVuls Blogを参考） 問題：スキャン結果が多すぎて開発者が動けない 34,000のコンテナイメージを毎日スキャン結果を更新→約2,690万件の脆弱性発見、24,536件のユニークなCVE そのうち66%はベンダーパッチが未提供（上流修正はあるがベンダーが未取り込み） スキャナーは「ベンダーが影響なしとしているか」「本当に悪用可能か」「偽陽性か」を判定しない VEX（Vulnerability Exploitability eXchange ※）オーバーレイシステムの設計 2段階パイプライン： Ubuntu（GitHub公開のVEX）とRed Hat（CSAF系VEX）を取り込み、正規化してCycloneDXとしてDBに格納 スキャン完了時にAPIがスキャンレポートにVEX情報を上書きする ルールエンジンでリスク許容度に応じた自動VEX適用ポリシーを設定 VEXアクションの優先順位（ルール） upgrade_suggested → 自動反映しない。修正版があるのでアップグレードを促す vendor_VEX-not_affected → Critical/High含む全深刻度で自動反映可 fix_available → vendor_VEX-not_affected より後順位で適用 vendor_VEX-affected → ベンダーが影響をMedium以下とする等、条件付きで自動反映し、開発者の追加調査の負担を減らす no_vex_or_upgrade_found → 原則は自動で判定せず。ただし最近公開された場合などはトリアージ中として扱う 実績データ 修正しなかったfindingsのうち94%でVEX情報に基づく判定が可能（CVE 2020以降） 中低深刻度1,700万件のうち84%にVEX情報が適用 Critical/Highは修正可能なものが多く積極的に修正指示 -2,600万件→VEX適用後、開発者が真に対応すべき件数を大幅削減 ベンダーが「影響なし」と言っていても顧客スキャナーでは検出されるため、SLAの設計が必要な課題として残る 学んだこと ベンダーごとのVEXフォーマット・更新頻度が異なり正規化が必須 スキャナー側がVEX情報を取り込んでいないケースがあり、業界全体での標準化・取り込みが課題 Alpine等まだ対応していないディストリビューションのVEX情報の取り込みが今後の課題 7. Contextual SBOMs: Unlocking Precise Vulnerability Management with Build-Time Content Intelligence 発表： Red Hat SBOMについて SBOM（Software Bill of Materials）は、ビルド工程で使われ、最終的なソフトウェアコンポーネントに含まれる全アーティファクトを機械可読で棚卸ししたもの 脆弱性管理において重要なのは、ソフトウェア資産全体の中からCVEを迅速に特定でき、修正の優先順位付けにも役立つため 規制（例：EU Cyber Resilience Act）やフレームワーク（例：NIST SSDF）でSBOM要求が増え、SPDX/CycloneDXやツール群で成熟してきた一方、複雑で現実的なコンテナビルドでは「SBOMが約束すること」と「実際に提供できること」にギャップがある 標準SBOM（Analyzed SBOM）の根本的な限界 コンテナイメージは複数のベース・ビルダーイメージからなるマルチステージビルドで構成 標準SBOMはフラットな「contains」リストのみを提供し、「なぜそのアーティファクトがそこにあるか」が不明 「誰が修正責任者か」がわからない状態でCVEが報告されるため、複数チームが無駄な調査・再ビルドに時間を浪費 誤った順序での再ビルドによりCVEが修正されない事態が起こり得る Contextual SBOMのコアコンセプト ビルドステップを精密に監視し、全アーティファクトをビルドアクション・生成イメージにマッピング 使用するSPDXのRelationshipType： CONTAINS ：コンテナイメージ内の標準的な包含関係 DESCENDANT_OF ：ベースイメージとの親子関係（例：アプリイメージ→UBI Python） BUILD_TOOL_OF ：マルチステージビルダーイメージとの関係 具体的な効果（ベースイメージの例） 脆弱なHTTPパッケージ検出時→Contextual SBOMから「UBI Pythonベースイメージに由来」と即座に判定 アプリケーション所有者ではなくベースイメージ所有者に通知 ベースイメージ修正後のCI/CDパイプラインの自動再ビルドを完全自動化 具体的な効果（ビルダーイメージの例） curl が脆弱→GoLang Builderイメージが起点と特定→アプリレイヤーにコピーされていない場合は最終アプリの再ビルド不要と判断可能 ソースコードの依存関係起因のCVE→ベースイメージ所有者・ビルダー所有者には通知不要 Contextual SBOM導入前後の比較 Before After アーティファクトの起源 不明 即座に特定可能 修正担当チーム 関係しそうなチームが巻き込まれ、担当特定に時間 担当チームを最初から特定でき、担当だけが動ける 再ビルド順序 試行錯誤・重複ビルド 最適な順序で自動実行 社内エスカレーション 全体アラートになりがち 「対応不要」と伝えられる 課題と呼びかけ アーティファクトの一意識別子（チェックサム・SPDXのPackage Verification Code）の一貫性が精度の前提 カスタムバイナリファイルなど一意識別子を持たないコンテンツでは起源特定が困難→「不確実状態」でフラグ付け SBOMツールエコシステム全体におけるContextual SBOM対応ツール開発への投資を呼びかけ Contextual SBOMの利用方法 Hermeto（※） 公開プロジェクトとして公開中、CI/CDパイプラインへの組み込み可能 ※Hermeto Project： https://github.com/hermetoproject 8. Lessons From NPM's Dark Side: Preventing the Next Shai-Hulud 発表： OpenSourceMalware.com 「偶発的脆弱性」vs「意図的マルウェア」の違い 偶発的：開発者のミスによるフロー、CVE対象、サードパーティライブラリが動いている場所で悪用、影響期間は長期間のケースがある 意図的：最初に感染するのは開発者PCやCI、影響期間は短命（axiosは3時間未満でレジストリから消えた）、シークレット窃取が主な目的 CVEの対処法（最新バージョンにアップグレード）が、マルウェアでは逆に感染経路になる なぜnpmが標的になるか postinstallなどのライフサイクルスクリプトがデフォルトで実行される（ダウンロード直後に感染） provenance（発行元証明）が必須ではなく、検証の習慣が根付いていない 長期有効トークン（Long-lived Access Token）が存在し、一度奪われると長期間悪用される さらにJavaScriptの推移的依存関係の多さも影響範囲の拡大を加速 2025年主要マルウェアキャンペーン（5件） eslint-config-prettier（7月）： 3800万DL/週。タイポスクワッティングドメインのフィッシングでトークン窃取→Windows開発環境でRCE is（7月）： 280万DL/週。「メンテナーの誤ったアクセス削除」を装うソーシャルエンジニアリング→クリプトウォレット・クラウドクレデンシャル窃取 NX（8月）： GitHubアクションの未発見脆弱性を悪用→AIツール（Claude・Gemini・Amazon Q）の設定を書き換えてマルウェアの共犯者化→370社・20,000ファイル以上流出（第2波で6,700リポジトリ追加公開） Quix（10月）： 26億DL/週。「2FA更新」を装うフィッシング→chalk・debugパッケージ含む28パッケージ侵害→$1,000相当の暗号通貨窃取 Shai-Hulud（9月・11月）： 187パッケージ掌握→TruffleHogを武器化してシークレットをスキャン→感染したパッケージを自動的に再公開するワーム機能→528リポジトリ公開化→第2波で492パッケージ追加侵害（ホームディレクトリ削除機能付き）→26,000リポジトリからクレデンシャル流出 2026年：TeamPCPによるTrivy・axios侵害 Trivy： 長期有効PATを悪用して悪意あるリリースを公開→LightLLMなど下流ツールも汚染 axios： 北朝鮮系脅威アクターによる高度なソーシャルエンジニアリング（偽のSlack連絡・偽のTeamsアップデート誘導によるマルウェア実行） Shai-Hulud第2波の被害を受けた組織の分析 侵害された30,000パッケージについて、どれだけの組織がシークレットをローテーションしたかを調査（Entro Security社による分析） 被害を受けた組織は1,000を超える 一定数の組織で、Shai-Hulud第2波から72時間後も有効なクレデンシャルを保持していた 被害組織は技術系企業だけでなく不動産・医療・保険など幅広い業種に及ぶ 防御策：npmメンテナー向け ハードウェアキー（YubiKeyなど）：ブラウザのオリジン不一致を拒否し、人的認証経路を保護 Trusted Publishing（GitHub OIDC）：CI/CDパイプラインのトークンを保護（採用率：過去ATO被害者で13%、Shai-Hulud被害者でさらに低い10.8%） セッションベーストークン（2025年12月npm導入）：長期トークンを廃止しExposure Window（露出期間）を縮小 防御策：利用者向け 開発者： バージョンピンニング、lockfile管理、自動アップデートの無効化、ライフサイクルスクリプトの無効化 プロダクトセキュリティ： 使用していない依存関係の削除、CIやAI IDE上でのマルウェアスキャン クラウドセキュリティ： シークレットローテーションの自動化・即時実行、異常なクレデンシャル使用の監視 インシデントレスポンス： 脅威インテリジェンスとのフィード統合、サプライチェーンのIRプレイブックの作成 Q & A パッケージ単位ではなく、リポジトリ単位でブロックするという考え方とは？ マルウェアを配布するには、パッケージ単体だけでなく、それを公開するためのインフラ（例：GitHubリポジトリ）が必要になる そのため、個々の悪性パッケージを追いかけるのではなく、以下の対応の方が、運用上効率的でスケールしやすいケースがある 悪性だと判明したGitHubリポジトリ自体をブロックする そのリポジトリから配布される成果物を包括的に遮断する クールダウン期間とは何か？なぜ有効なのか？ 新しいパッケージやバージョンを公開直後にすぐ使わず、一定時間待ってから利用する運用のこと 推奨される待機期間：2〜3日（理由：アカウント乗っ取りなどで公開された 悪性バージョンの多くは、その期間内に削除・検知されている） 攻撃を完全に防げるわけではないが、何もしない場合に比べてリスクを大きく下げられる実用的な防御策とされている クールダウン運用で問題になりがちな点は？ 重大な CVE 対応など、即時アップデートが必要な例外ケースが必ず発生する そのため、クールダウンを前提とする場合は、次が不可欠である 技術的にクールダウンを回避できる仕組み 誰が・どの条件で例外を承認するかという事前合意 実際の運用では、「24時間以内に全社が即時アップデート必須」というケースは稀 理論上の緊急性と、現場で実際に対応できる現実にはギャップがある まとめ VulnCon 2026では、脆弱性管理を取り巻くエコシステムが大きな転換点にあることが示されました。 NVDやCVEといった基盤は引き続き重要である一方、npmパッケージのマルウェアキャンペーンの事例が示すように、サプライチェーン攻撃のスピードと複雑さは増しており、単一の制度や指標だけでは実運用に耐えない場面が増えています。 また脆弱性管理において、VEXやContextual SBOMによる影響範囲の文脈化に加え、VulnCheckの発表が示したような「実際に悪用されている／されやすいか」という視点を組み合わせる重要性が強調されていました。 本記事で紹介したセッションは、これらの変化と課題を理解するうえで特に参考になる内容が多かったと感じました。 ちなみにバーチャル参加の場合、TLP:CLEARかつ2日目以降のセッションしか視聴できませんでした。 ネットワーキングパーティやワークショップへの参加、TLP:GREEN以上のセッションを視聴したい場合は、現地参加をご検討ください。 https://www.first.org/events/calendar/2027#start:2027-03-30 CVE/FIRST VulnCon 2027 & Annual CNA Summit - Save the Date Scottsdale, US March 30, 2027–April 2, 2027 私たちは共に働いていただける仲間を募集しています！ みなさまのご応募、お待ちしています！ 株式会社電通総研 新卒採用サイト 株式会社電通総研 キャリア採用サイト 執筆： @fukuyama.kenta レビュー： @kobayashi.hinami （ Shodo で執筆されました ）