エージェントを自分で作ってみるべき理由

 (fly.io)
51 ポイント 投稿者 GN⁺ 2025-11-07 | 2件のコメント | WhatsAppで共有
  • LLMエージェントは、単なる概念として理解するよりも、自分で実装してみることで動作原理を実感できる技術的な構造
  • たった数十行のPythonコードでOpenAI Responses APIを使った対話型エージェントを作成でき、ここに**ツール呼び出し（tool call）**機能を加えると自律的な行動が可能になる
  • エージェントの中核は、ステートレスなLLMとの反復呼び出しループであり、会話コンテキストを自分で管理することで複数ターンの会話を実現する
  • Context Engineeringは実際のプログラミング課題レベルの問題であり、トークン制限の中で入力・出力・ツール説明を最適化する設計が必要
  • 現在のエージェント設計は開かれたソフトウェア工学の問題空間であり、個人開発者でも実験を通じて新しいアプローチを試せる領域

エージェントを書くことのシンプルさ

  • LLMエージェントは、複雑な設定なしにOpenAI Responses APIひとつで実装可能
    • 例のコードではcontextリストを通じてユーザーとモデルの対話を保存し、これを繰り返し呼び出すことでChatGPTのような対話型応答を生成する
  • 「良い性格」と「悪い性格」を持つ2つのコンテキストを作り、多重人格会話をシミュレーションできる
    • LLMには状態がなく、会話の連続性はユーザーが管理する**文字列配列（context）**によって維持される
  • このシンプルな構造だけでも複数ターンの会話が可能で、LLMの動作原理を直接体験できる

ツール統合と自律的な動作

  • エージェントにping関数をツールとして登録し、ネットワーク接続状態を確認する機能を追加
    • OpenAI APIはJSON形式でのツール定義を要求し、LLMが必要に応じてツール呼び出しを要求すると、Pythonコードがこれを実行して結果を再び渡す
  • LLMは明示的な指示がなくても、複数のホスト（google.com、www.google.com、8.8.8.8）に自動でpingを実行する
    • これはLLMが「ツール使用権限」だけでも自律的な判断を行ったことを示している
  • 全体のループは単に「ツール呼び出し要求 → 実行 → 結果返却」という構造で、複雑な制御ロジックがなくても自律エージェントの動作を実装できる

実際の応用とMCP批判

  • 例のコードはシンプルだが、ここに追加ツール（tracerouteなど）やSQLiteベースのコンテキスト保存を組み合わせれば実用的に拡張できる
  • **MCP（Multi-Context Protocol）**はClaude CodeやCursorのプラグインインターフェースにすぎず、必須技術ではない
    • APIを直接扱えば、MCPなしでも同じ機能を実装できる
  • MCPはコードの制御権がない環境でのみ有用で、むしろエージェントアーキテクチャの柔軟性を制限しうる
  • LLMのセキュリティは複雑だが、分離されたコンテキストとツール制限によって安全な構造を設計できる

コンテキストエンジニアリングの重要性

  • 「プロンプトエンジニアリング」は誇張された概念だが、コンテキストエンジニアリングは実際のプログラミング問題
    • コンテキストウィンドウ内のトークン数には制限があり、入力・出力・ツール説明がすべて容量を占める
    • この限界を超えると、モデルの応答品質が不安定になる
  • 解決策として、**サブエージェント（sub-agent）**を作ってそれぞれに異なるコンテキストとツールを与え、互いに要約・交換するよう設計できる
    • このような構造は、ツリー型エージェントネットワークやリアルタイム要約ベースの圧縮など、さまざまな実験へ拡張可能
  • 複雑なアイデアでも、30分以内に実装できる程度のシンプルさを持つ

開かれた工学問題と実験の価値

  • 現在、多くのスタートアップが脆弱性検出用エージェントを開発しており、個人開発者でも同様の実験が可能
  • エージェント設計には次のような未解決の工学課題が含まれる
    • 非決定性と構造化プログラミングのバランス
    • 現実検証（ground truth）とループの早期終了防止
    • 多段エージェント間のデータ交換形式（JSON、SQL、Markdownなど）
    • トークン配分とコスト制御
  • これらの問題は大規模研究ではなく、個人単位の実験でも探求可能な領域であり、各反復は数十分以内で試せる
  • 結論として、自分でエージェントを作ってみる経験こそがLLM技術理解の出発点である

関連記事

2件のコメント

 
2025-11-09
[このコメントは非表示になっています。]
 
GN⁺ 2025-11-07
Hacker Newsの意見

  • やりたいことが本当に多い。NANDゲートでCPUをブレッドボード上に自作してみたいし、RustでCDNも作ってみたいが、時間が足りない
    その代わりにKarpathyのチュートリアルに沿ってLLMを作ってみたが、こういうふうに少しずつ実験していくのはかなり良いと感じた

    • 終わりのない曲線のように感じる。以前は8ビットコンピュータをブレッドボードで作っていたのに、今度は飛行訓練（PPL）に夢中になっている
      いつも「これでやり切った」と思うたびに、ゴールがさらに遠ざかる感じがする。結局、こういう人間は完全には満足できない類いなのだと思う
    • TFAの序盤では、それがどれだけ簡単にできるかを説明している。それこそがこの記事の核心だ

  • 例ではGPT-5を使っているが、クエリインターフェースはすでに業界標準レベルだ
    たとえば OpenRouter.ai をつなげば、実行時にモデルとプロバイダを簡単に切り替えられる
    無料モデル（例: DeepSeek）も提供されているが、遅くて制限も多い。それでも実験用としては優秀だ

  • 数か月前、Rubyでエージェントを自作してみた。本当に楽しかった
    中核ロジックはたった4行で、概念的には驚くほどシンプルだった

    until mission_accomplished? or given_up? or killed?
  determine_next_command_and_inputs
  run_next_command
end

  • 2年前にPHP 25行でエージェントを作ったが、当時はtool callingもなかったのにかなりうまく動いた
    LLMは自分にとって sed や awk のようなUNIXのテキスト処理ツールに感じられる — 入力と命令を与えると出力を返す構造だ
    こうしてLLM呼び出しを組み合わせ、ループや分岐を作るとかなり強力なシステムになる
    関連コード: hubcap, llm

    • hubcapが本当に好きだ。コード量は少ないのに結果が印象的だった
      Simon Willisonの記事を見て大きな刺激を受けた

  • Claude Codeの代替を自分で作るという部分に特に共感した。自己改善型コーディングエージェントを作るのは、ほとんど魔法のような体験だ
    モデルを自由に差し替えられるし、Cerebrasのような高速なモデルを使うと対話型のツール呼び出しでも大きな違いを感じる
    そこにメモリや音声認識などを追加すれば、さらに効率的になる。数分で実装できて本当に楽しい

    • どの音声認識モデルを使っているのか気になる。Whisperは遅くて正確ではなかったし、GPTオーディオモデルは拒否応答をよく返す
      Googleのモデルは品質が低く、Mistralのモデルは速いが、たまにテキストに反応してしまう
      そのせいで、ときどき自分が話した内容の代わりに、LLMの意識の流れが文字起こしされることがある
    • 「build your own lightsaber」という表現が本当に気に入った
      最初は内部構造を理解するために作ったが、思ったより単純だったので、今では自分の欲しい機能を直接追加している
      チーム単位の製品より速く機能を入れられる。エージェントは驚くほど単純な構造だ
    • 入門するならどこから始めればいいのかわからない。Cerebrasが何なのかも初めて聞いた。今はVS CodeでCopilotを使っているだけだ
      これがローカルモデルベースなのか気になる
    • Cerebrasは今ではglm 4.6を提供している。相変わらず非常に速く、しかも今ではずっと賢くなっている

  • この記事を読むと、Unix哲学 — ひとつのことをうまくやるツール — をもう一度作りたくなる
    エージェントを単純にするだけでなく、セキュリティも高められる

    • 2021年にネットワーク接続をテストするエージェントを作ったが、ping, dig, traceroute のような基本ツールをエージェントに任せると、かなり良い結果が出る
      人間が直接作ったテレメトリシステムほど完璧ではないが、90%レベルの有用性をはるかに簡単に達成できた
    • 人間に直接公開される限定目的のツール群を想像してみることもできる
    • ひとつのことをうまくやるには、より多くのツールが必要になり、そのぶん文脈理解力も大きくなる
      LLMの理想的なサイズは、従来のUnixツールより少し大きい中間地点にある気がする

  • 「エージェントを本当に作る必要があるのか？」という疑問が湧く。
    すべてのAIプロバイダが赤字を出している状況で、持続可能な収益モデルが成立するのか懐疑的だ

    • 自分で作ってみれば、エージェントの仕組みと限界を直感的に理解できる。それが核心だ
    • これは単に技術を遊びで試すための記事だ。収益化とは無関係だ
      Pythonを使わない理由としてAstralの赤字を持ち出すのと似た理屈だ
    • すべてのAI企業が赤字というわけではない。
      次のモデル訓練コストが大きいため資金が必要なのであって、推論段階は収益性がある
    • 自分自身がAIプロバイダになることだってできる
    • このコメントには少し感情的な疲労感がにじんでいる。もしかしてキャリアの長い開発者なのだろうか

  • コンテキストエンジニアリングの部分が特に刺さった
    自分は個人アシスタントを作っているが、一般的なエージェントよりも記憶、作業追跡、問題解決能力を多く持たせている
    複数のエージェントが互いに会話しながら問題を解決するよう設計しており、最初のエージェントはタスク管理の監督者の役割を担う
    この過程が深まるほど、どんどんエンジニアリング上の問題へと変わっていく
    詳しくは 自分のブログ記事 にまとめてある

    • 本当にすばらしいプロジェクトに聞こえる

  • みんなエージェント作りは好きだが、デバッグは嫌いだ
    最初は魔法のようにうまく動くのに、次第に確率的な失敗が積み重なって再現が難しくなる
    1ステップごとに0.5秒かかるので、どこで間違ったのか確認するには10〜20分も待たなければならない

    • だから自分は並列実行ツールを作って、修正したコードを何百回も回し、
      過去のシナリオも再実行して何も壊れていないか検証している

  • 提供されたコードをもとにMCPを作ってみた: gurddy-mcp.fly.dev
    ソースコードは GitHubリポジトリ で見られる