なぜ今、フレームワークを捨てて実装するのか
日々の開発現場において、LangChainやLlamaIndexといった強力なフレームワークは、もはや空気のような存在だ。しかし、シニアエンジニアとして自問自答したい。我々は、それらのライブラリが裏側で何をしているのか、本当に「自分の言葉」で説明できているだろうか。PyConJP 2026で野澤氏が提示した「フレームワークに頼らないピュアPythonでのCoding Agent実装」というアプローチは、まさにこのブラックボックス化に対する強烈なアンチテーゼである。
多くのエンジニアが、LLMのAPIを叩き、ツールを定義し、エージェントを動かす際に、抽象化された高レベルなAPIの背後に隠れた「状態管理の泥沼」を見落としている。野澤氏の実装は、わずか200〜300行（LLM SDKのみに依存）という極めてミニマルな構成で、エージェントの骨格を浮き彫りにした。これは単なる学習用コードではない。エージェントが「思考」し、「ツールを実行」し、「エラーから自律回復」するプロセスを、泥臭いPythonのコードとして可視化した点にこそ、真の価値がある。
我々が直面する「エージェントがなぜか変な挙動をする」「無限ループに陥る」といった障害は、多くの場合、この思考ループの設計思想を理解していないことに起因する。本発表で示されたディレクトリ構成は、types.pyによる型定義の統一、providers/によるSDKの抽象化、そしてcore/による思考ループの分離という、極めて堅牢な設計パターンを提示している。これは、単に動くものを作るのではなく、保守可能でテスト可能なエージェントを構築するための「エンジニアリングの作法」そのものだ。フレームワークの裏側にある複雑性を、自らの手で再構築することで初めて、我々はAIエージェントを「魔法」から「制御可能なソフトウェア」へと昇華させることができるのである。
思考ループとガードレールの実装論
Coding Agentの心臓部は、LLMとツール実行を交互に繰り返す「思考ループ」にある。野澤氏の実装において特筆すべきは、異常系を例外処理として握りつぶすのではなく、あえて「会話履歴」に積むという設計思想だ。これは、LLMを単なる推論エンジンとしてではなく、エラーメッセージを読み解き、自ら修正案を導き出す「自律的なエージェント」として扱うための極めて重要な戦略である。
例えば、editFileツールにおける差分編集のロジックを見てほしい。変更前の文字列がファイル内に一意に存在する場合のみ編集を許可し、曖昧な場合はエラーを返す。このエラー文言は、人間への通知であると同時に、LLMに対する「次のステップへのプロンプト」として機能する。この「エラーを対話の一部にする」という設計は、デッドロックや無限ループといった、分散システムや並行処理で我々が長年苦しめられてきた課題に対する、AI時代ならではの回答と言えるだろう。
また、セキュリティの観点から実装されたガードレールも極めて実践的だ。execCommandにおけるシェルインジェクション対策として、シェルを介さずに自前でパーサーを実装し、subprocess.runへ渡すというアプローチは、セキュリティを「おまじない」ではなく「設計」として組み込む姿勢の表れである。以下の表は、本実装における最小構成の要点をまとめたものである。
| 構成要素 | 役割 | 実装のポイント |
|---|---|---|
| LLM API | 推論とツール選択 | SDKの差異を吸収する共通インターフェースの構築 |
| Tool実行 | ファイル操作・コマンド実行 | descriptionによるプロンプトエンジニアリングと安全なパス検証 |
| 思考ループ | 状態遷移の管理 | エラーを会話履歴に含め、自律回復を促す設計 |
| ガードレール | 安全性の担保 | サンドボックス、承認フロー、ステップ上限による暴走防止 |
これらの要素を疎結合に保ち、cli.pyで統合する設計は、将来的な拡張性を担保する。最小構成で動くことを確認した後に、ext/モジュールとしてコンテキスト圧縮やSub Agentを切り出す手法は、まさにスパゲッティコードを回避するための王道的なリファクタリングのプロセスそのものだ。
AIエージェント時代にエンジニアが問われる本質
最後に、我々エンジニアが明日から取るべき行動について考えたい。AIエージェントの台頭により、コーディングの定義は「コードを書くこと」から「エージェントの思考プロセスを設計すること」へとシフトしつつある。しかし、どれほど高度なエージェントが登場しようとも、その背後にある「ファイルシステムへの理解」「プロセス管理」「エラーハンドリング」といった古典的なコンピュータサイエンスの知識が不要になることはない。むしろ、AIがコードを生成するからこそ、そのコードの正当性を検証し、ガードレールを敷くエンジニアの「審美眼」がこれまで以上に重要になっている。
野澤氏が示した「作って理解する」というアプローチは、単なる技術的探究心を満たすためのものではない。それは、AIという不確実性の高い技術を、自らの制御下に置くための「生存戦略」である。もしあなたが、既存のフレームワークをブラックボックスとして使い続け、何か問題が起きた際に「ライブラリのバグだ」と嘆くだけの存在になりたいのであれば、この実装を無視してもいいだろう。しかし、もしあなたが、AIを道具として使いこなし、複雑なシステムを自律的に構築できるエンジニアを目指すのであれば、今すぐフレームワークのソースコードを閉じ、ピュアPythonでエージェントをゼロから実装してみるべきだ。
我々が直面しているのは、AIがコードを書く時代における「エンジニアの役割の再定義」という問いである。AIが生成したコードのデバッグに追われるのか、それともAIを制御するアーキテクチャを設計するのか。その分かれ道は、あなたが今、この「思考ループ」を自分の手で実装しようとするか否かにかかっている。エージェントの暴走を止めるのは、高度なAIモデルではなく、あなたが書いたガードレールのロジックであるという事実を、我々は決して忘れてはならない。さあ、あなたのエージェントは、本当に信頼できる設計になっているだろうか？
コメント