Piは最後のハーネス（エンジン）

Piは最後のハーネス（エンジン）

2026年11月1日

全てが変わる

AIコーディングの世界では、全てが急速に進んでいることに気づかないわけにはいきません。以前は全てのツール呼び出しを承認するのが普通でしたが、今ではそれは狂気の沙汰の兆候です。MCPは、良く、悪く、そして再び良くなりました。「プランモード」は存在しましたが、今ではレガシーです。人間のコードレビューは死につつあります。延々と続けることができます。

LLMは私たちの周りの全て、私たちが世界を操作する方法、そして信号をどのように受け取るかを変化させています。コーディングはこの変化の中心にあり、最も影響を受けています。それは変化しただけでなく、変化のペースはSotAモデルの進歩のペースに直接導かれています。

コーディングに関しては、現在のプロセスが何であれ、それは変化し続けるでしょう。疑いなく、今後数年間は業界の全員にとって激動の時期となるでしょう。

一定に保たれるものもある

驚くべきことに、多くのことは同じままです。

興味深いことに、私たちが常にベストプラクティスと考えてきた儀式の多くは、今日でも有効です。ドキュメントの作成（および保守）、良好なテストカバレッジ、ドメイン固有および汎用の静的チェック、モジュール化されたコード、バージョン管理の衛生状態、堅牢なアーキテクチャ — これらは炭素ベースのコーダーに利益をもたらしたものが、言語モデルにも計り知れない利益をもたらすようです。

特にコーディングハーネスに関しては、多くのことがそのまま残ると予測しています。モダリティは依然として「テキスト入力、テキスト出力」でしょう。ツール呼び出し（主にbashとMCP、と推測します）は引き続き利用されるでしょう。適切な抽象化レベルでのオブザーバビリティを重視するでしょう。

さらに重要なのは、このペースの速いダイナミクスにおいて、モデルを指示するために使用するツールの安定性と信頼性を重視するということです。安定した基盤を望みつつ、その周りの全てを成形できることを望むでしょう。私たち自身の意見を上に構築するために、意見を押し付けないものを望むでしょう。あなたをロックインしようとせず、あなたにコントロールを委ねるソフトウェアを賞賛するでしょう。

なぜPiなのか？

Piがここに最適である理由は？シンプルです：それは今日、オープンソースであり、ベンダーに依存せず、拡張可能で、あなたに意見を押し付けないほどミニマルな唯一のハーネスです。それはあなたに完全な所有権を与え、あなたをコントロール下に置きます。アプリを切り替えずにプロバイダーを変更できることだけでも採用する理由になりますが、それが非常に柔軟であるという事実は、私が元に戻ることをほぼ不可能にしています。

ミニマルであることは2つの理由で重要です。第一に、ミニマルであることで、モデルの能力を制限するブロート（特にフロンティアモデルに害を及ぼします）を導入しません。第二に、リーンに保つことで、廃止された機能をアンシップする必要がなくなります。

拡張可能であることはさらに重要です。2つのワークフローが同じ機能性を保証するほど似ていることはありません。私はAskUserQuestionツールの大ファンですが、他の人はそれを必要としないかもしれません。私が使用する全てのプロバイダーにわたるプロバイダー制限を示す/usageコマンドのようなものを持っていることを好みますが、他の人はそれを望まないかもしれませんし、異なる形式でそれを望むかもしれませんし、異なるプロバイダーを使用するかもしれません。誰もこれらの決定を強制されるべきではありません。

この時点であなたは異議を唱えるかもしれません：「Piは今最高のものかもしれませんが、将来も最高の選択肢であり続けることができるのでしょうか？」

もっともな質問です。2つの理由があると思います。

Piはリンディ効果です。それは1年間存在しており、おそらく全てのハーネスの中で最大の開発者コミュニティを持っています。それはここに留まるでしょう。

別途、Piは十分に良いので、代替が桁違いに優れているとは予想していません。切り替えるには、通常10倍良いものが必要です。Piは確かにClaude CodeやCodexと比較して大きな飛躍です。想像力がないというリスクを冒して、Piを超える10倍の改善が何であるかを理解できません。確かに、クラウドエージェント、動的なワークフロー、モデルルーティング、より良いプラグインシステムのような、欠如が取引を破る可能性のある特定の機能はありますが、それらがネイティブまたはプラグインを介してPiの一部に最終的にならない方法を私は見ていません。

ハーネスは間違った言葉

「ハーネス」という言葉は過剰に使われすぎています。異なる人々はそれに対して異なる定義を持っており、それは一種のミームコンセプトになりました。同時に、ハーネスは目に見える明白な利点なしに、裏ではるかに高度になっています：耐久性、洗練されたプラグインシステム、一貫した体験におけるプロバイダー固有の機能の調和。

代わりに、「ハーネスエンジン」または単に「エンジン」という言葉を使いたいと思います。エンジンは、プロンプトやツールに関するものではありません — それらは時間とともに収束するでしょう。エンジンはプロバイダー間の統一されたインターフェースを提供し、コンパクションを処理し、失敗したリクエストを自動的に再試行し、トランスクリプトを整理します。それはユーザーが自分のニーズに合わせて調整する基盤です。

一つの賭け

私は個人的にPiが勝つと思います。私はそれに取り組むことで、この賭けに私の時間を費やすことをいといません。

他のハーネスのサポートを追加する計画はありません。一つのものに集中することによってのみ、あなたは素晴らしい製品を作ることができます。そうでなければ、それはそれらの間の最低公倍数になるだけです。

次は何？

もちろん、「最後のハーネス」は誇張です。私は実際にもはや試みがないとは思っていません。しかし、Piが最後の広範なエージェンティックコーディングハーネスになるチャンスがあると思います。

個人的には、以下に注目しています：

• Orbs / Amp: エフェメラルなワークロードごとのVMのファーストクラスサポートは、生産性を大幅に向上させます。現在全ての作業をVMで行っている者として、共有リソースの管理、パッケージの更新、資格情報のプロビジョニングに多くの時間を費やしてきました。コードに集中できるものを使いたいと強く思います。
• DeepSeek Harness: アプリの全てをプラグインにするというやや急進的なアイデアですが、方向性としては正しいと思います。Piでは、あまりにも意見が強すぎるものがいくつかありますが、それについて私にできることは何もありません。
• omp²: ompの作成者であるCan Bölükは、新しいメジャーリリースに照らしてハーネスの詳細な内訳を共有しました。個人的な最大のテイクアウェイは、ハーネス/エンジンの設計は未熟な分野であり、拡張API、トランスクリプトとジャーナリング、プロバイダー処理、ツール、そしてランタイム自体など、ほぼ全てを再考する機会があるということです。

---