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

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

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

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

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

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

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

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

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

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

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

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

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

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

金融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 で執筆されました ）