GitHubの注目ツール、AIエージェントの最大の問題を即座に解決

AAI LABS
컴퓨터/소프트웨어

스크립트

00:00:00OpusやGPT 5.6のような優れたモデルを使えば通常は良い出力が得られますが、これらのモデルは
00:00:06トークンも大量に消費します。GPT Astraのようなハイエンドモデルではさらに状況が悪化し、
00:00:11Fable 5.1なども含め、他のモデルに比べてはるかに早く利用制限に達してしまいます。
00:00:16また、処理速度も非常に遅いため、1つのタスクが完了するまでに長い時間を待たされることになります。この
00:00:21まさにその問題を解決するため、最近GitHubでトレンドになっている「graft」というツールがあります。これは
00:00:26これらのエージェントがデフォルトでプロジェクトを処理する方法を改善するものです。トークンを節約できるだけでなく、
00:00:31エージェントを単独で動作させる場合よりも大幅に高速化してくれます。非常に興味深いアプローチを採用しており、
00:00:36この問題がそもそも発生する根本的な原因を解決してくれます。この問題を解決するために作られたツールが
00:00:40これまでになかったわけではありませんが、どれも大きな欠点があり、まさにそこをこのツールが解決しています。
00:00:46初めての方へお知らせすると、私たちはソフトウェア会社であり、ここはチャンネル「AI Labs」です。この
00:00:51動画では、graftを使用することでこれらのモデルの利用コストをいかに安く抑えられるかを詳しく紹介します。その前に、
00:00:56graftについて解説する前に、何かを変更する前にエージェントがなぜこれほど多くのトークンを消費するのかを理解する必要があります。
00:01:02Claude CodeやCodexのようなエージェントがファイルを検索する際に使用するデフォルトの方法には問題があります。
00:01:07作業中のアプリに何かを追加するようエージェントに求めると、まずはその変更を記述すべきアプリの部分を
00:01:12見つけなければなりません。その部分を見つけるために、ターミナル上で追加したいものに関連する単語を
00:01:17検索するさまざまなコマンドを使用します。モデルは通常、探しているものを一発で見つけることはできず、
00:01:23検索対象を正確に絞り込むために複数のツールを使用する必要があります。モデルが次にどのツールを使うべきかを判断するたびに、
00:01:28エージェントはこれまでのすべての会話(すでに使用したツールからの応答を含む)をモデルに送信します。
00:01:32モデルはそのすべてを読み込んで次のステップを決定するため、
00:01:37何度もやり取りを重ねた末にようやく正しいファイルにたどり着きます。
00:01:42そのやり取りの1回1回に使用制限のコストがかかります。例えば、エージェントにボタンを
00:01:47緑色にするよう依頼した場合、まずそのボタンのコードが含まれているファイル自体を見つける必要があります。そのため、
00:01:53ボタンを含むファイルを検索し、その結果があなたのメッセージと共にモデルに送信されます。次にエージェントは、
00:01:58別のツールを使用してそのファイルから特定のコード行を読み込み、それを行って初めて実際に
00:02:04変更を加えます。要求したすべての変更は、このような試行錯誤を経て行われます。すべての
00:02:08メッセージやツールの結果が何度も送信されるため、コンテキストウィンドウが肥大化し続けます。コストがかさむだけでなく、
00:02:14モデルの動作も遅くなります。なぜなら、この方法ではモデルが複数のターンを消費して
00:02:19必要なファイルを絞り込んでいるため、新しい検索のたびに情報が増え、モデルはその処理のために
00:02:25トークンを消費してどうするかを判断しなければならないからです。これが、1回のセッションで多くのタスクを
00:02:30エージェントと一緒に作業しているときに利用制限に達してしまう理由の1つです。さて、利用制限に達することは1つの結果に過ぎず、
00:02:36コンテキストウィンドウに情報が多すぎるために出力の品質が低下するという問題もあります。エージェントが
00:02:41一度に一つのことに集中できなくなるのです。これは既知の問題であるため、
00:02:46これを解決しようとするツールはすでに存在します。これらのツールが採用している一般的なアプローチは、コードのセクションを
00:02:51「ベクトル」と呼ばれる数値に変換し、モデルが簡単に比較できるようにすることです。質問を投げかけると、
00:02:56検索ツールはその質問もベクトルに変換し、最も一致度の高いセクションを見つけ出します。
00:03:02これはベクトル検索と呼ばれ、基本的には質問と意味がどれほど似ているかによって情報を探す手法です。
00:03:07しかし、類似性だけではアプリのパーツがどのように繋がっているかまでは分かりません。例えば、
00:03:12アカウント作成のコードとアカウント削除のコードはどちらもアカウントに関する質問に一致する可能性がありますが、
00:03:17やっていることは正反対です。そのため、間違った方を選んでしまうと非常に大きな代償を払うことになります。
00:03:21これが、この検索があまり効果的ではなく、ほとんどのコーディングエージェントで使用されていない理由です。
00:03:26そのツールに進む前に、チャンネル登録と高評価ボタンを押していただけると大変嬉しいです。
00:03:30このささやかなサポートが私たちの大きな励みになります。さて、graftは実際にはコンピュータにインストールする
00:03:36ターミナルコマンドであり、変更を加えるたびにコーディングエージェントがプロジェクト内を検索し続けるという
00:03:41デフォルトの動作を変更するために作られています。これを実現するために、
00:03:46プロジェクト内のすべてのパーツのマップである「ナレッジグラフ」を構築し、さまざまなパーツが
00:03:51どのように繋がっているかを示します。エージェントはそのマップを使用して必要なコードを見つけ、どの他のパーツが
00:03:57それに依存しているかを確認します。これは実質的に無料でオープンソースであり、最大の特徴は
00:04:02別個のAPIキーを持つモデルを使用しないため、普段のサブスクリプションのままで動作する点です。また、オプションのステップとして、
00:04:07モデルを使用してアプリに関する平易な解説ページを作成する機能もあります。これにより、コードの各部分が何をするものか、
00:04:12パーツがどう噛み合っているかが説明されます。マップ自体がすでにエージェントに何がどこに繋がっているかを伝えているため、
00:04:17このステップは必須ではありませんが、コードの機能に関する説明が追加されます。このページがあることで、エージェントは
00:04:22すべてのファイルを開くことなく、各パーツの役割を把握できるようになります。graftの開発チームが
00:04:28このツールを実行したところ、トークン使用量の観点でエージェントを4分の1のコストで運用できることがわかりました。これはベストケースでの結果であり、
00:04:33162回の実行にわたる独自のベンチマークでは、タスクにかかる時間が平均で60%短縮され、エージェントがツールを使用する回数が46%減り、
00:04:42トークンも42%削減され、コストは平均で32%低くなりました。そしてこの節約効果は、エージェントが
00:04:48検索しなくてよくなること全体に由来するため、大規模なプロジェクトほど効果を発揮します。小さなプロジェクトでは
00:04:53そもそも節約できる検索があまりないためです。graftはClaude Codeや
00:04:58Codexのほか、ターミナルコマンドやMCPを使用する他のコーディングエージェントとも連携します。しかし、構築されるマップは
00:05:04先ほどお話ししたベクトル検索とは異なります。graftはコードを数値に変換して類似性で一致させるのではなく、
00:05:09コードを読み込んでどの部分が実際にどこを使用しているかを書き留めます。そのため、1つのパーツを変更したときに、
00:05:14その変更によって他の何が壊れる可能性があるかをエージェントが正確に把握できるようになります。また、コードが変更されると
00:05:20すべてを最初から作り直すのではなく変更された部分だけを更新するため、マップは常に自律的に最新の状態に保たれ、
00:05:25エージェントがプロジェクトの古いバージョンに基づいて作業することは決してありません。それではまず、
00:05:30スポンサーであるHydraからのメッセージをご覧ください。私たちはアプリにAI生成機能を追加しようとしていましたが、それは以前なら
00:05:35モデル、インフラ、ジョブキューをご自身で管理しなければならないことを意味していました。そこでHydraのAPIの出番です。彼らは
00:05:41モデルの背後にあるランタイムとAPI全体を構築しているため、そうしたインフラをすべて自分で立ち上げる必要はなく、
00:05:46そのレイヤー全体がすでに処理されています。私たちのコードから実際に1回呼び出しを行うと、アセットが突然現れるのではなく、
00:05:51追跡可能な実際のジョブが返され、「キュー登録中」から「処理中」、「完了」へと
00:05:56メディアが返されるまでの様子を確認できました。このステータス表示こそが重要なポイントであり、これによって
00:06:02これが実際のプロダクション作業に対応できることが分かります。自分のアプリに組み込むのもわずかなコードで済み、
00:06:07CLIやSDKも用意されているため、ターミナルやエディタから直接作業できます。これは、1人の開発者では
00:06:13これまで構築できなかったようなものです。Hydra.comでHydraを無料で試して、初月が50%オフになるコードをご利用ください。
00:06:19リンクとコードは以下の説明欄にあります。何かをインストールする前に、graftが実際にどのようにそのマップを作成するのかを
00:06:24見ておく必要があります。マップを構築する際、graftはコンピュータ上のコードを読み込み、
00:06:29見つかったすべてのパーツの名前とプロジェクト内での場所を書き留めます。
00:06:34そして、どのパーツとどのパーツが繋がっているかを記録します。マップ上の各パーツは「ノード」と呼ばれ、
00:06:392つのパーツ間の各接続は「エッジ」と呼ばれます。したがって、エージェントがアプリの特定のパーツを使用しているものを尋ねると、
00:06:44graftはそれらのエッジをたどり、検索していたものに関連するコードを提供します。
00:06:49これにより、変更が他の何かに影響するかどうかを確認できるようになります。これはまさにベクトル検索には
00:06:53できなかったことです。graftはそのマップをコンピュータ上にJSONファイルとして保存します。JSONとして保存する理由は、
00:06:59その形式であれば詳細が添付された適切な構造でデータを書き留めることができるからです。また、
00:07:04ブラウザで開くビューアも用意されており、マップを確認して接続を探索することができます。graftが
00:07:10Claude Codeに接続されると、セッションの開始時にマップを使用するための指示をモデルに与えます。
00:07:15その後、プロンプトを送信するたびに、graftはメッセージ内の単語とマップを照合し、
00:07:20最大3つの一致する場所をそれに添付します。これにより、モデルは単一のツールを使用する前に、
00:07:26どのファイルと行を読めばよいかをすでに把握しています。コード自体は、エージェントがそれらの行を読み込むときに初めてコンテキストに入ります。
00:07:32そのため、モデルは少ないターンで正しいファイルにたどり着き、コンテキストウィンドウに追加される情報も大幅に少なくなります。
00:07:37その結果、高速化され、制限の消費も抑えられます。MCPオプションもあり、違いは
00:07:43どちらが検索を開始するかという点です。先ほど説明した設定では、graftがプロンプトから推測して、
00:07:48エージェントが必要としているかどうかに関係なく、すべてのメッセージにそれらの場所を添付します。MCPを使用する場合は、
00:07:53プロンプトに何も添付されず、エージェントは本当に必要なときにだけgraftに問い合わせます。graftの独自テストでは、
00:07:58MCP版の方がCLI版よりも正確な回答を多く得られ、CLI版は処理速度の面で優れていました。
00:08:04インストールすると両方手に入ります。アプリを変更すると、graftは自動的にマップを最新の状態に保ちます。
00:08:10質問に答える前に、マップが構築されてからコードが変更されたかどうかを確認し、変更されていれば
00:08:15モデルを使用せずにまずマップを更新します。さて、graftをインストールするには説明欄にリンクのあるサイトにアクセスし、
00:08:20そこからインストールコマンドをコピーするか、使用しているコーディングエージェント用のセットアッププロンプトを
00:08:25コピーして、それをエージェントに直接貼り付けます。そのセットアッププロンプトには、
00:08:30エージェントがgraftをインストールしてプロジェクトにセットアップするために必要なすべてのコマンドが含まれています。もしその部分を
00:08:35ご自身で行いたい場合は、サイトからインストールコマンドをコピーして任意のフォルダの
00:08:40ターミナルで実行すれば可能です。一度インストールされれば、CLIはすぐに使用できます。プロジェクト内で使用するには、
00:08:46initコマンドを実行してそのプロジェクトにgraftを設定する必要があります。このコマンドは、
00:08:52作業中のフォルダー内で実行する必要があります。そのフォルダー内にそのプロジェクト用の
00:08:57指示が追加されるためで、別の場所で実行すると失われてしまいます。実行すると、使用している
00:09:02コーディングエージェントを尋ねられます。エージェントごとに独自のセットアップが必要なためです。
00:09:07Claude Codeを使用していたためそれを選択し、インストールを進めました。
00:09:11それが完了すると、プロジェクトフォルダーにgraphスキルが表示されます。これはエージェントに
00:09:16graphの使い方やコマンドを指示するものです。フックもインストールされます。フックとは何かというと、
00:09:22設定されたポイントで独自に実行される小さなスクリプトのことです。これらのフックにより、エージェントは
00:09:26graphのワークフローに従うよう強制されます。複数のフックがインストールされ、1つはセッション開始時に
00:09:31マップを使用するための指示をモデルに与え、別のものは送信するプロンプトに一致する場所を添付し、
00:09:37最後のものはClaudeがファイルを編集した後に実行されてマップが常に最新の状態に保たれるようにします。
00:09:41次に、すでに作業を進めているプロジェクトでこれをセットアップする場合、その同じフォルダーで
00:09:46graph buildコマンドを実行し、graphに既存のすべてのコードを調べさせて
00:09:50そこからマップを構築させる必要があります。空のフォルダーで始める場合はまだマップするものがないため、
00:09:56ファイルが存在するようになったらClaudeに構築させます。その後は通常通りClaude Codeを実行し、
00:10:01マップビューアでgraphが作成したノードとエッジを確認します。空のフォルダーではマップは0ノードから始まり、
00:10:06ファイルが作成されるにつれてgraphがそれらを追加していきます。さて、私たちはfable 5.1を使用し、
00:10:13カレンダーのように独立したプロバイダー向けの予約・スケジューリングアプリを構築してgraphをテストしました。
00:10:18このモデルはトークンを非常にすばやく消費するため、間違ったタスクに労力を費やしてほしくありませんでした。
00:10:23そのため、作業を始める前に一連のステップを踏みました。まずアプリの仕様をまとめたPRD(製品要件定義書)を作成し、
00:10:29アプリに必要なすべての機能を把握できるようにしました。また、このモデルに合わせてカスタマイズされた指示を含み、
00:10:34目標から逸れることなく長時間の処理を実行できるようにするclaude.mdファイルも追加しました。
00:10:40そのclaude.mdファイルは、私たちのコミュニティ「AI Labs Pro」でテンプレートとしてアップロードしているものなので、
00:10:46同じテンプレートを使用しました。ファイルは単なるテンプレートだったため、まずはPRDを基にして
00:10:51claude.mdの空欄を埋めるよう指示しました。PRDがない場合は、構築しているものをプロンプトで直接伝えても構いません。
00:10:57claude.mdを更新したら、モデルをfable 5.1に切り替え、アプリの構築プロンプトを
00:11:02使用したいツールとともに与えました。このモデルには、単独で作業していることを明示的に伝える必要があります。
00:11:07これは前回のfable 5.1の動画で取り上げたので、途中で停止して許可を求めないよう指示しました。graphを使用した場合、
00:11:14ビルドにかかった時間は39分で、コンテキストウィンドウの約31%を使用しました。graphなしの場合、同じビルドに47分かかり、
00:11:20約35%を使用しました。両方のアプリで機能は実質的に同じでした。そのため最初のビルドでは、この時点ではまだ
00:11:25グラフが構築されていなかったため差はわずかでしたが、変更を加え始めるとその差は大きくなりました。
00:11:30その時点ではすでにgraphがプロジェクト全体のマップを持っていたからです。ランディングページの完全な刷新には
00:11:352分もかかりませんでした。graphなしであれば、同じ変更にはもっと多くの時間がかかっていたでしょう。
00:11:40変更後、graphは新しいファイルでマップを更新し、その処理で節約されたトークンの推定値を表示しました。
00:11:46そして、知っておくべき最後のことが1つあります。実際のプロジェクトで作業する場合、
00:11:50コードだけでなく、構築しているものに関するコンテキストをエージェントに提供する他のファイルも含まれています。
00:11:56これにはPRDや各種領域特有のファイル、learnings.mdファイルなどが含まれますが、
00:12:03graphはコードしかマップ化しないため、PRDやメモはマップ化されません。つまり、それらを読み込む必要がある場合、
00:12:09エージェントは通常通りのデフォルトの方法を使用します。それはさておき、私たちのように多くの人が
00:12:14コーディング以外の多くのタスクにもClaude Codeを使用しています。そのため、そうした用途にもツールを適応させるため、
00:12:20複数のプランファイルが存在する実際のプロジェクトでも使用できるように少し修正を加えました。
00:12:25そしてそのバージョンを私たちのコミュニティであるAI Labs Proに追加しました。私たちの活動に価値を見出し、
00:12:31チャンネルをサポートしたい場合は、それが一番の方法です。リンクは説明欄にあります。これで今回の
00:12:36動画は終わりとなります。チャンネルをサポートし、このような動画の制作を続けられるよう協力していただける場合は、
00:12:41下のスーパーサンクスボタンをご利用ください。いつもご視聴ありがとうございます。また次回の動画でお会いしましょう。

핵심 요약

GitHubのトレンドツールであるgraftは、プロジェクトのナレッジグラフを構築してエージェントの検索プロセスを効率化し、トークン消費量を42%削減する。

하이라이트

  • graftツールの導入により、コーディングエージェントのタスク処理時間が平均60%短縮される。

  • コードベースのマップ構築により、エージェントのツール使用回数が46%減少する。

  • graftを使用することで、AIコーディングのトークン消費量が42%削減され、コストが平均32%低くなる。

  • プロジェクト内のすべてのパーツの接続関係を示すナレッジグラフをJSONファイルとして保存する。

  • コードが変更された際には変更部分だけが自動的に更新され、マップが常に最新の状態に保たれる。

타임라인

AIコーディングエージェントにおけるトークン消費の問題点

  • ハイエンドモデルはトークンを大量に消費し、利用制限に早く達する。
  • エージェントはファイルを検索するために複数回の試行錯誤と会話のやり取りを繰り返す。
  • 従来のベクトル検索はコードの類似性のみを比較するため、パーツ間の依存関係を正確に把握できない。

優れたAIモデルは高品質な出力をもたらす一方で、膨大なトークンを消費し処理速度が低下する。ボタンの色を変更するような単純な指示であっても、エージェントは関連ファイルを特定するために何度も検索ツールを呼び出し、コンテキストウィンドウが肥大化する。これまでの解決策であったベクトル検索は意味の類似性で情報を探すため、反対の機能を持つコードを誤って選択するリスクがある。

graftの仕組みとナレッジグラフの構築

  • graftはプロジェクト内のパーツのマップであるナレッジグラフを構築する。
  • 別個のAPIキーを持つモデルを使用せず、通常のサブスクリプションのままで動作する。
  • コードを読み込んでパーツ間の依存関係をエッジとノードとして記録する。

graftはコンピュータ上で実行されるターミナルコマンドであり、プロジェクト内のすべてのパーツのマップを作成する。コードを変更した際に何が壊れるかをエージェントが正確に把握できるよう、パーツの名前や場所、接続関係をJSONファイルとして保存する。ベクトル検索とは異なり、実際にどの部分がどこを使用しているかを書き留めるため、正確な依存関係の追跡が可能になる。

CLIとMCPの動作モードおよびインストールと実践

  • graftにはCLI版とMCP版の2つのモードが存在する。
  • initコマンドとbuildコマンドを実行することでプロジェクトにセットアップされる。
  • ベンチマークにおいて、タスク時間が平均で60%短縮され、コストが32%低くなった。

graftをインストールした後は、initコマンドで設定を行い、buildコマンドで既存コードのマップを構築する。CLI版はプロンプトに一致する場所を自動添付して処理速度を高め、MCP版は必要なときだけエージェントが問い合わせることで正確性を高める。実際のベンチマークテストでは、タスク時間が60%短縮され、エージェントのツール使用回数やトークン消費量が大幅に削減された。

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기