Transcript
00:00:00先月はループエンジニアリング、その前はコンテキストエンジニアリングでしたが、今日の新しい
00:00:05トレンドはグラフエンジニアリングです。しかし、これは実際に理解すべきものなのでしょうか、それとも
00:00:11AIブームの乗りに任せて、無意味なトピックにおしゃれなタイトルをつけているだけでしょうか？この
00:00:17動画ではその疑問にお答えします。ネタバレすると、これは決して無意味なトピックではありません。さて
00:00:23グラフエンジニアリングは、作るものすべてに適用されるわけではありませんが
00:00:28特に複雑なループを使う人なら、理解しておきたい概念です
00:00:33自分に当てはまると思う方や、近いうちにそうなる予定の方は、ぜひ最後までご覧ください。グラフエンジニアリングは、ループエンジニアリングの拡張や進化にすぎません
00:00:43そこで、全員の認識をあわせるために、ループエンジニアリングとは何かを迅速におさらいしましょう
00:00:47すべてのループには大きく分けて3つのセクションがあります。1つ目はトリガーです。どのように
00:00:54実際に開始されるか？理想的には自律的で、毎日決まった時間に実行されるか、イベント駆動型です
00:01:00ステップ2はタスクです。実際に何を行っているのか？そしてステップ3では、何らかの成功基準が必要です
00:01:07何をするよう指示しているわけですが、正しく実行されたかをどう判断するのでしょうか？なぜなら
00:01:13正しく完了しなかった場合、最初から再実行させたいからです。理想的にはすべてが自動実行され、データが
00:01:19どこかに保存され、自己改善のような要素すら追加できるようにすることです。しかし、基本骨格としては
00:01:25トリガーが必要であり、何かを実行し、それが成功したかをテストできる必要があり、それらが
00:01:30すべて自動化されているべきです。今回の例では、毎朝のレポートを生成する
00:01:35ループを用意しました。このAIエージェントは毎日午前7時に実行されます。これがトリガーです
00:01:42タスクは、YouTube、Twitter、Redditなどの様々なソーシャルメディアプラットフォームをチェックし
00:01:47AIに関するトレンド情報を探すことです。そして、メールもチェックさせます。それらすべてを行ったら
00:01:54情報を統合してレポートを作成させます。これがタスクです。この場合、成功基準は少し曖昧です
00:02:00レポートが正しく作成されたかをどう定義するのでしょうか？今回のケースでは
00:02:05「この種の情報を含め」「この長さにして」とループに指定しています
00:02:11「リンクも含めるように」といった具合に、測定するための基準を与えています。これが
00:02:17私たちのループです。とてもシンプルですね。単一のエージェントによって実行されます。では、これをどのようにグラフに変えるのでしょうか？
00:02:25全く同じタスクを想定したまま、ループエンジニアリングからグラフエンジニアリングへ移行するにはどうすればいいでしょう？
00:02:30毎日のモーニングレポートを完成させたいという目的は変わりません。見てみましょう。右側にあるのが
00:02:35同じタスクをグラフエンジニアリング化したバージョンです。同じレポートを得ようとしていますが
00:02:40作業を行うエージェントの数を増やしています。具体的には、1つのエージェントがすべてを行う形から
00:02:46特定のタスクを行う複数のエージェントが相互に連携する形に変更しました。したがって
00:02:53トリガーは同じです。毎朝7時に実行されます。しかし、YouTubeを担当するエージェントが1つ
00:02:58Twitterを担当するエージェントが1つ、Redditに1つ、そしてメールを担当するエージェントが1つ存在します
00:03:04各エージェントは必要な情報を取得します。そして
00:03:09それぞれ独自に情報をまとめ、その要約をレポート担当の
00:03:17エージェントに送信します。レポート担当エージェントはデータを収集し、目的のレポートへとさらに要約します
00:03:23さらに一歩進めて、レビュー専用のエージェントを配置することもできます。このエージェントは
00:03:30生成されたレポートを独自に確認し、成功基準として定義したものと比較して
00:03:36全体をもう一度ループ処理すべきか、そのまま本番に出力して良いかを判断します
00:03:41これがグラフエンジニアリングの概要です。では、これを分解して詳しく見てみましょう。「エージェントを
00:03:48増やしただけで、何が起きたのかよく分からない」と思うかもしれません
00:03:51たしかにエージェントを追加しましたし、それには明確な理由があります。グラフエンジニアリングが
00:03:58少し複雑になる理由は、単に仕組みを複雑にしたいからではなく、すべてのタスクを取り出して
00:04:03それぞれを独自のループエンジニアリングを実行するエージェントへと変換したからです。以前はどうだったでしょうか？
00:04:09ループエンジニアリングでしたよね？すべての処理を行い、成功基準をチェックしていましたが
00:04:14非常に大まかなレベルで、一度にいくつもの異なる処理を行っていました。それに対してグラフエンジニアリングでは
00:04:181つの特定タスクにズームインし、YouTubeの分析と調査だけを行う
00:04:22専用のエージェントを用意しました。それ自体もループエンジニアリング構造に落とし込んでいます。考えてみてください
00:04:291つのタスクに縮小されていますが、これもループエンジニアリングです。トリガーがありますよね？同じく
00:04:34午前7時です。タスクもあります。YouTubeでAIに関する情報を見つけ、それを
00:04:39要約する必要があります。そして3つ目として、成功基準も存在します。しかし、これを
00:04:46グラフエンジニアリング構造にしたことで、プロセスの各ステップにおける「成功」の定義を
00:04:51非常に具体的に設定できるようになります。例えば、「情報源を少なくとも5つ取得すること」や
00:04:57「要約は少なくとも2段落以上にすること」、あるいは「見つけたすべての情報源と情報に対して
00:05:03『だから何なのか（So What）』を明記すること」といった具体的な条件を設定できます
00:05:09つまり、検証プロセスを非常に大雑把に行い、すべてをまとめて「うまくいった」「いかなかった」と判断するのではなく
00:05:16個別のセクションに分解したのです。なぜこれを意識する必要があるのでしょうか？
00:05:22まず第一に、品質が向上します。1つのエージェントにすべてをやらせるのではなく、1つのエージェントに
00:05:271つのことだけをやらせるからです。純粋にコンテキストの劣化という観点から見ても
00:05:33一度に10個のことをこなそうとするエージェントに比べて、コンテキストウィンドウが比較的クリアに保たれるため
00:05:40より良い出力が得られます。さらに、処理速度も向上します
00:05:441つのエージェントが10個の処理を行う代わりに、4つのエージェントが並列で4つの処理を行うからです
00:05:51そのため、より速く、効果的で、問題が発生したときの特定も容易になります。なぜなら
00:05:56それがYouTubeの問題なのか、Redditの問題なのかをすぐに判別できるからです。単一のループでは
00:06:03「プロセスのどこで間違えてレポートが不採用になり、修正に送り返されたのか」というノイズの中から
00:06:08シグナルを見分けるのが難しくなります。繰り返しになりますが、これはサブタスクごとに成功基準を
00:06:15定義できるようになったからです。これがグラフエンジニアリングの概要であり、注目すべき理由です
00:06:20単一のエージェントではなく、一連のエージェントが存在し、それらが多様な方法で連携しています
00:06:27タスクをアトミック（最小単位）な形で個別に分解しているのです。アトミックな
00:06:33タスクだからこそ、何をさせたいか、何が成功なのかをタスクごとに非常に具体的に設定できます
00:06:38そして各エージェントは、本質的に独自にループエンジニアリングされた
00:06:44構造体となります。複数のループを繋ぎ合わせた状態です。ここで次に生じる疑問は
00:06:48「では、どのような時にループエンジニアリングではなくグラフエンジニアリングを使うべきなのか？」ということです
00:06:54正直なところ、常にこのような超複雑なマルチエージェント構成を作る必要はありません
00:06:58まったく不要です。多くの場合、シンプルなループで十分足ります。しかし、グラフエンジニアリング構築を
00:07:04検討すべきシナリオが3つ存在します。まず最初のシナリオは
00:07:09コンテキストの問題、特にコンテキストの劣化に直面している場合です。1つの
00:07:15エージェントに何度もループを回させ、各ループで4つ、5つ、6つ、7つ、8つとタスクをこなさせ
00:07:20実行ごとのコンテキストウィンドウが30万、40万、50万トークン規模に達する場合は
00:07:25作業を分割するのが賢明です。コンテキストウィンドウが埋まることで
00:07:29出力品質が低下するリスクを、無理に引き受ける必要はありません。次に、シナリオ2は独立したレビューが必要な場合です
00:07:36適切なループについて考える際、どこかの時点で成功判定、つまり例の成功基準のチェックを
00:07:41行う必要があります。作成物（今回の例ではレポート）を作成した当のエージェント自身に
00:07:48「これが良かったか・悪かったか」を自己判定させることが妥当かを考える必要があります。モーニングレポート程度であれば
00:07:55自己判定で十分かもしれません。それほど複雑ではなく、失敗のリスクも低いため
00:08:01「このレポートはまあまあ良い」と判断させるのも悪くありません。内容も主観的なものですしね。しかし、リスクが高く
00:08:07第三者の目によるチェックが必要な場合は、グラフエンジニアリング化を検討し
00:08:13全く別のエージェントを導入して成果物を検査させる必要があります
00:08:18そのエージェントはCloud Codeのエージェントである必要すらなく、GPT 5.6のようなモデルかもしれません
00:08:24いずれにせよ、マルチエージェントオーケストレーションを組むシナリオでは、グラフエンジニアリングが
00:08:28非常に効果的です。そして3つ目の要素は処理時間です。どれくらい迅速な動作が必要でしょうか？
00:08:32今回のケースでは、グラフエンジニアリングによる自動化が極めて有効です。なぜなら、1つのエージェントに
00:08:37YouTubeを見て、次にTwitter、次にReddit、そしてGmailを見させる必要があるでしょうか？
00:08:44Cloud Code自体もそんなやり方はしません。ディープリサーチなどを実行した時
00:08:48それらの情報源を1つずつ順番にリサーチしているでしょうか？いいえ、100個もの
00:08:52サブエージェントを一度に展開して処理を行っています。実際、Ultra Codeやダイナミックワークフローを使って
00:08:57Cloud Codeが生成するほぼすべての仕組みは、何らかの形のグラフエンジニアリングです。複数のエージェントが
00:09:02情報収集を行い、複数のエージェントが要約を行い
00:09:08複数のエージェントが収集した情報の敵対的検証（レビュー）を行っています。そうした
00:09:13複雑なセットアップにおいて、単一のループに依存している箇所は一切ありません。代わりに、ループ化されたエージェントの
00:09:17ネットワークとなっています。しかし冒頭で述べた通り、皆さんが行うタスクの大部分は、これら
00:09:233つのカテゴリのどれにも当てはまりません。当てはまらないのであれば、グラフエンジニアリングを使う理由は特にありません。それは
00:09:28ツールボックスにある道具の1つに過ぎないのです。必要な時もあれば、不要な時もありますが、活用すれば大きなメリットが得られます
00:09:34一方で、必要もないのに無駄に複雑なステップやインフラを追加してしまうという
00:09:39デメリットも存在します。グラフエンジニアリングについての解説は
00:09:44このあたりで終わりにしたいと思います。グラフエンジニアリングとは何なのか、少しでも理解が深まっていれば幸いです
00:09:48今後、この話題を何度も耳にすることになるでしょう。しかし、ループエンジニアリングを理解していれば
00:09:52「ループエンジニアリングを実行する複数のエージェントが連携して動作しているだけ」と捉えることができます
00:09:57エージェント同士が会話しながら協調することで、品質が向上し
00:10:01処理速度が上がり、どこで何が問題になっているのかを特定しやすくなります。そして自分の
00:10:07タスクにそれが必要かどうか分からない場合、答えは「おそらく不要」です。それでは
00:10:12感想をぜひコメント欄で教えてください。Cloud Codeマスタークラスに興味がある方は
00:10:17Chase AI Plusをぜひチェックしてみてください。概要欄にリンクを貼っておきます
00:10:24それでは、また次の動画でお会いしましょう
00:10:27それでは、またお会いしましょう。