Transcript
00:00:00「グラフエンジニアリング」という新しい言葉が流行しており、Xでも大きな話題になっています。
00:00:04グラフの前は「ループエンジニアリング」が主流で、エージェントに目標を与えて自律的に
00:00:09作業させていました。しかしグラフを使えば、ループよりも遥かに高速かつ広範囲の作業を
00:00:14一度に処理できます。ただ、グラフには大きな問題があります。一部の小さなエラーが
00:00:18出力全体を台無しにしてしまい、最終結果しか見えないため原因特定も困難なのです。
00:00:23そこでAnthropicが、まさにこの問題を解決しグラフの失敗を防ぐ新機能を公開しました。
00:00:27初めての方へ、私たちはソフトウェア企業であり、このチャンネル「AI Labs」では
00:00:32AIを活用してビジネスを最適化する方法を紹介しています。
00:00:37自身のビジネスがなくても、これらのスキルを使って他社を最適化し、報酬を得ることも可能です。
00:00:42今回は、グラフエンジニアリングの基礎と
00:00:46Anthropicが提案する解決策を解説します。まず、グラフエンジニアリングを理解する前に
00:00:52ループエンジニアリングとは何かを知る必要があります。既にご存知の方はスキップしてください。
00:00:56ループとは、エージェントに任せる一連の作業サイクルのことです。ステップごとにプロンプトを
00:01:02入力する代わりに、到達すべき最終目標を指示すれば、状況に応じて調整しながら自律的に進めてくれます。
00:01:07自社のワークフローでも多用しており、構築方法を詳しく解説した動画も
00:01:12既に公開しています。しかし現在、ループは「グラフ」へと進化しつつあります。
00:01:17ループの問題点はその構造にあります。
00:01:22ループでは作業を行った後、検証ステップが入って正しく処理されたかを確認します。
00:01:27合格して初めて次のステップへ進みます。すべてが一直線に実行されるため、無関係な作業であっても
00:01:32前のステップの完了を待つ必要があります。グラフエンジニアリングはまさにこれを解決します。
00:01:37一直線に実行するのではなく、タスクを小さく分割し、各パートに専用のエージェントを割り当てます。
00:01:42最大のメリットは速度です。1つのエージェントが順にこなすのではなく、複数のエージェントが同時に進めるためです。
00:01:47また、タスクごとに最適なモデルを選択できるため、コストもある程度抑えられます。
00:01:52高度な知能を必要としない処理に、一番高価なモデルを消費せずに済むのです。
00:01:56ただしこれはエージェント単体のコストであり、全体のコストではありません。グラフは1つではなく
00:02:01複数のエージェントを同時に動かすため、単一エージェントより遥かに多くのトークンを消費します。
00:02:07グラフを使う場合、制限に達するのがこれまで以上に早くなるため
00:02:12Claude CodeやCodexの月額20ドルプランだけでは運用が難しくなります。
00:02:17Claude Codeを使っている方なら、ダイナミック・ワークフローというグラフの形を
00:02:22既に目にしているはずなので、まったく新しい概念というわけではないでしょう。
00:02:27ダイナミック・ワークフローは渡されたタスクを複数のサブエージェントに展開しますが、
00:02:33これこそがグラフの基本的な動きです。グラフの構成パターンに入る前に、
00:02:38その構成要素を理解する必要があります。すべてのグラフは「ノード」と「エッジ」の2つでできています。
00:02:44ノードとは、全体タスクから切り出された個々の仕事のことで、独立して実行されます。
00:02:49隔離されたコンテキストウィンドウで作業を行い、報告を返すエージェントです。
00:02:55それらの独立した仕事を繋ぐのが「エッジ」です。エッジはノード間のデータ移動を制御し、
00:03:01あるエージェントの出力を適切なタイミングで適切なエージェントに届けます。
00:03:06そのため、すべてのノードはグラフ全体と何らかの形で接続されている必要があります。
00:03:10例えば、複数のエージェントが同じ作業レビューを行う場合、お互いの完了を待つことはありません。
00:03:15しかし同じデータから出発し、すべてのレポートが最後に1箇所に集約されます。
00:03:20これがグラフの仕組みです。次に、これらの要素がどう配置されるかのパターンを見ていきましょう。
00:03:25最初は以前チャンネルで紹介した形です。当時はグラフエンジニアリングという言葉がなく、
00:03:30「ループ」と呼んでいましたが、実際にはループさせていたグラフであり、形状は「ダイアモンド型」でした。
00:03:35トップの1つのタスクが並列で動く複数のサブエージェントに分散し、最後に1つの
00:03:41エージェントに集約され、すべての発見事項を1つの回答にまとめます。
00:03:46次に「ファンイン・バリア型」です。これは1つの対象を複数の視点から同時に評価したい場合に向いています。
00:03:51ファンアウト部分で同じ問題を複数のエージェントに振り分け、それぞれ異なる観点からチェックさせます。
00:03:56全員の報告が揃うまで次へ進まず、揃った段階で初めて修正処理を実行します。
00:04:00他にも多くの形状がありますが、どれも同じ土台の上に成り立っています。
00:04:05それが「検証（Verification）」です。このチェック体制を適切に構築しないと、
00:04:10後続のすべてのエージェントが間違いの上に作業を重ねることになります。
00:04:15検証の話に入る前に、チャンネル登録と高評価をお願いします。皆様の応援が励みになります。
00:04:20エージェントの大群を動かすようになると、単一エージェントでは起きない問題が発生します。
00:04:25一番の問題は単純に作業量です。全員が同時に動くため大量の成果物が一度に返ってきて、
00:04:30最後にレビューするのが非常に困難になります。もう1つの問題はブラックボックス化です。
00:04:34何か問題が起きても、何が原因で失敗したのかを特定する手段がありません。
00:04:39現状、あらゆるエージェントは指示の有無にかかわらず自分の書いたものを検証しようとします。
00:04:44コードの場合、テストを実行して返ってきたエラーをキャッチする程度です。
00:04:49しかしそれでは致命的なエラーしか拾えません。コードの書き方自体はチェックされないため、
00:04:53Claudeがそのまま書き続ければ、将来的に問題を引き起こす原因になります。
00:04:58Claude Codeにはこのための組み込みツールがいくつかあります。1つ目は「verifyスキル」で、
00:05:03最初から最後までコードを追い、想定通り動作するかを確認します。2つ目は「ツール・チェイニング」で、
00:05:08検証のために各種ツールを順次実行します。Claudeは作業チェック用ツールを実行すべきだと理解しており、
00:05:13エラーメッセージを読み取って自分で修正します。プロジェクト固有のコマンドも自力で
00:05:18割り出せますが、`Claude.md`ファイルに書いておけば毎回特定する手間を省けます。
00:05:243つ目は基準に照らし合わせてチェックする「コードレビュー・スキル」です。
00:05:29標準搭載されていないエージェントもありますが、なければ作成を依頼すれば作ってくれます。
00:05:33ですが最も効果的な検証は、組み込み機能だけに頼らず自ら構築することです。
00:05:38成果物を検証するスキルを最速で作るには、Claude Codeの「skill-creator」プラグインを使います。
00:05:44このスキルはCodexでも使用可能です。
00:05:49プラグインコマンドを実行し、skill-creatorを検索してインストールします。そこから
00:05:542つの選択肢があります。ユーザースコープで導入すれば、どのフォルダで作業していても利用可能です。
00:05:58あるいは、現在作業中のプロジェクト限定でインストールすることもできます。
00:06:03常に使うスキルなので、今回はユーザースコープを選択しました。
00:06:07スラッシュコマンドでプラグインを再読み込みすれば、skill-creatorが使用可能になります。
00:06:12次に作ってほしい内容を伝えます。ここで求める検証の具体的な仕様を記述します。
00:06:17私たちは主に、完成品が最初の要求を満たしているかをチェックするレビュー・スキルを使っています。
00:06:22グラフでは各エージェントが自分の担当部分しか見えないため、このプロセスが非常に重要になります。
00:06:28元の要件と照らし合わせて検証する手段になるからです。しかしスキルの精度は
00:06:32実行するモデルの性能に左右されます。コミュニティサイトのUI検証システムを作った際、
00:06:37安価でタスクも単純に見えたため、レビュアーをHaikuで動かしてみました。
00:06:43すると大量の問題リストが返ってきました。検出数だけ見れば、素晴らしい仕事をしたように思えました。
00:06:47しかし、全く同じ処理をOpusで実行すると、指摘事項は大幅に減りました。
00:06:53一見劣化に見えましたが、理由を読むと納得でした。Haikuが指摘した多くは
00:06:58意図して残した仕様であり、検出された問題のほとんどが完全に不要なものでした。
00:07:03Opusは周辺コードからそれを読み取りましたが、Haikuは見落としたのです。
00:07:08レビュー自体を再確認する羽目になり、安いレビューを選んでも節約になりませんでした。
00:07:13これを、多数のノードが同じスキルで自作コードを検証するグラフ構造に当てはめてみてください。
00:07:18壊れてもいない部分の修正に、エージェントが時間とトークンを無駄にし続けます。
00:07:23しかも複数のエージェントで同時に起きるため、どこが起点かも特定できません。
00:07:27つまり選ぶモデルは、レビューの質だけでなく
00:07:31グラフ全体の品質をも左右します。評価を担当するノードでのトークン節約は、致命的なコスト増に繋がります。
00:07:37もう1つの判断要素は、そのスキルをいつ・どう呼び出すかです。
00:07:41大きく3つの種類に分かれます。詳しく解説する前に、スポンサーからのお知らせです。
00:07:46Webからリアルタイムデータを取得したことがあるなら、スクレイピングの過酷さをご存知でしょう。
00:07:51CAPTCHAやレート制限と戦い、プロキシに悩み、本番環境に出した途端崩れるレイアウトと
00:07:56格闘する羽目になります。そこで役立つのが、開発に集中できるよう問題をすべて解決してくれる「SERP API」です。
00:08:01リクエストを1回送るだけで、必要なデータだけが綺麗なJSON形式で返ってきます。
00:08:07稼働率は99.9%以上、応答時間は約1.2秒です。AIエージェントの構築時には、
00:08:14最新情報を必要とするエージェントにGoogle Search APIを向けたり、Google Scholar APIで
00:08:20メタデータ付きの査読済み論文を取得させたりできるため、多くの商用エージェントで重宝されています。
00:08:25概要欄のリンクまたは画面のQRコードから、250の無料クレジットを受け取って始めましょう。
00:08:32スポンサーのSERP APIに感謝します。1つ目の種類は「スタンドアロン型」で、
00:08:37ユーザーが手動で実行した時のみ作動するスキルです。既存の成果物を深く分析するために
00:08:42作られており、完成品を精査できます。だからこそ毎回の実行後に自動起動させるべきではありません。
00:08:48未完成の成果物に対して重いレビューを行うとトークンの無駄になります。私たちが以前使ったのは
00:08:53Cursorの「thermonuclear code review」です。複数のエージェントを分散させ、それぞれ異なる
00:08:59セキュリティの観点からコードを検査します。すべての発見事項が1箇所に集まるため、
00:09:04まとめて修正に取り組めます。これはアプリ完成時に一度だけ実行すべきレビューの典型例です。
00:09:10これを作る場合、単にプロンプトで指示するよりskill-creatorを使うのが賢明です。
00:09:15テスト済みのものが生成され、信頼性が高まるからです。プロンプトでレビューしたい領域を指定し、
00:09:20簡易チェックではなく深い精査を求めていると伝えるため、「網羅的（comprehensive）」と明記してください。
00:09:26しかし手動実行が必要なスタンドアロン型は、作業中のノードには使えません。そこで役立つのが
00:09:31「埋め込み型（Embedded）スキル」です。指示しなくても、実行中のワークフローの一環として自動発動します。
00:09:36例えば新機能が要求された際に起動するスキルを作れます。作成されたコンポーネントが
00:09:41スキル内で定義したルールに沿っているかを確認し、合格するまで実装を完了させません。
00:09:45埋め込みスキルは自作できますが、前述のverifyスキルのように
00:09:50プリインストールされたものを自動呼び出しすることはできません。
00:09:54それらの命令は製品内部に組み込まれており、ユーザーが編集できないからです。
00:10:00自作するには、機能実装ごとに検証ステップを実行するようskill-creatorに指示します。
00:10:05新機能が既存の動作を破壊していないか検証するため、端から端までテストするよう伝えます。
00:10:10するとClaudeがスキルを作成してくれます。skill-creatorが生成したため、
00:10:16プロセスの一環として構造化・テストされた参照情報やスクリプトが付属します。
00:10:21機能を検証する際、デフォルトではChromeブラウザを開き、ページを読み込んで
00:10:26スクリーンショットを撮影する「ブラウザテスト」が使われます。
00:10:31ブラウザの自動操作によく使われるPuppeteerやPlaywrightを連携させている場合も
00:10:36同様の動作をします。しかしChromeはメモリ消費が激しく重いことで有名で、
00:10:41ワークフロー内で何度もページを確認するには遅すぎ、時間を圧迫し始めます。
00:10:46かなりの時間を奪われ始めます。そこで「Chrome Headless Shell」と呼ばれる軽量な方法があります。これは
00:10:52ブラウザの簡易版です。エージェントは同様にページにアクセスしてスクリーンショットを撮りますが、
00:10:57通常のChromeよりも遥かに高速に処理を完了します。
00:11:02これを検証スキルに直接組み込めば、エージェントが構築したあらゆる機能を
00:11:07毎回設定することなく視覚的に自動チェックできます。これとは別に、
00:11:12自社ワークフローで最も多用しているのが「セカンド・オピニオン（second opinion）」スキルです。理由はシンプルです。
00:11:17成果物を構築したエージェント自身は、レビュー役として最も不適格だからです。
00:11:23構築に使ったのと同じコンテキストで評価するため、先入観を持った判定になります。一方、新しいClaudeセッションは
00:11:28経緯を一切知らないため、偏りのない客観的な評価と率直なフィードバックが得られます。
00:11:33Claudeにも似たような組み込みアドバイザーがありますが、現在のチャット履歴を読み込むため
00:11:38結局同じコンテキストを引き継いでしまいます。過去の文脈を排したレビューが欲しい時にこそ、セカンド・オピニオンを使います。
00:11:43`-p`フラグを使って実行中のセッション内部から別のClaudeセッションを立ち上げることで機能します。
00:11:48このフラグはバックグラウンドで独立したClaude Codeセッションを起動し、プロンプトを渡して処理させます。
00:11:53ただし使用にあたって注意点がいくつかあります。完全に別のセッションを立ち上げるため、
00:11:57回答が返ってくるまでにかなり時間がかかります。
00:12:02また、より賢い「セカンドオピニオン」を得ることが目的である以上、モデルの選定が何より重要です。
00:12:07そのため、そのセッションをOpusで開始するよう明示的に指示する価値があります。
00:12:12これにより、グラフ内の各ノードは作成に関与していない賢いモデルに成果物を検証してもらえます。
00:12:18ただし1つのスキルで全領域をカバーすることはできません。適切なレビューを行うには
00:12:22複数の異なる観点から評価する必要があり、それぞれの視点に異なる評価基準が存在します。
00:12:27すべてのレビュー手法を1つのスキルに詰め込むと、考慮事項が多すぎてエージェントの精度が低下してしまいます。
00:12:33そのため視点ごとに独立したスキルを構築し、それらを連結（チェーン）させます。
00:12:38Anthropicの開発チームも同様の手法をとっています。彼らは「code-review」スキルを
00:12:43「simplify」や「verify」スキルと連携させており、これら3つはClaude Codeに標準搭載されています。
00:12:49さらに彼らは独自のデザインスキルも運用しており、製品のデザイン決定事項が詰まった
00:12:54`design.md`ファイルとインターフェースを照合させています。つまり4つの方向からレビューを行っているのです。
00:12:59最終的には、それぞれ異なる領域をカバーする一連のスキル群に行き着くことになります。
00:13:04しかしエージェントにそれらを一度に全部実行しろと指示するだけではうまくいきません。
00:13:09必要なのは全体を統括する「オーケストレーター・スキル」です。他のスキルを実行することだけを目的とします。
00:13:15保持しているレビュー・スキルごとにエージェントを立ち上げ、それぞれのスキルを割り当てます。
00:13:20全員が各自の独立したコンテキストで同時にレビューを行い、すべての指摘事項を1つのレポートに集約して
00:13:25修正担当エージェントに渡します。こうすればグラフを構築する際、
00:13:30その1つのスキルを使うようプロンプトで指示するだけで済みます。
00:13:35立ち上がったすべてのノードがそのスキルを読み込み、配下でレビュー全般が自律的に展開されます。
00:13:40今回、グラフの検証環境を構築するすべての手順をまとめたドキュメントを用意しました。
00:13:45その資料と動画内で紹介した全スキルは、私たちのコミュニティ「AI Labs Pro」で公開しています。
00:13:50動画の内容が役に立ち、チャンネルを応援したいと思ってくださる方は、ぜひご参加ください。
00:13:55リンクは概要欄にあります。これで今回の動画は終了です。チャンネルを支援し、
00:14:00今後の動画制作を応援していただける方は、下のSuper Thanksボタンをご利用ください。ご視聴ありがとうございました。次回お会いしましょう。