Pi Vs HagiCode

主な機能

Pi CLI の能力は、固定の単一プロバイダー体験ではなく、制御可能な AI 実行に焦点を当てています：

プロバイダーファーストのモデルアクセス：Pi は一つの固定されたベンダー経路を強制するのではなく、異なるモデルバックエンドを指 定できます。そのため、一つの CLI ワークフローを保ちつつ、時間とともに基盤となるプロバイダーやモデル戦略を変えたいチームにとって魅力的です。

設定可能な思考とセッションの振る舞い：Pi は思考モード、セッションディレクトリ、セッションなし実行などのスイッチを公開しています。タスクに応じて、実行をまたいで会話状態を保つか、各ターンを完全にステートレスにするかを選べます。

明示的なツールガバナンス：Pi は AI のターンにどれだけのツールアクセスを与えるかを決められます。より厳しい安全境界やより予測可能な実行振る舞いが欲しいときは、組み込みツールやより広いツール使用を無効化できます。

技術アーキテクチャ

Pi にはいくつか注目すべきアーキテクチャ上の特徴があります：

構造化された CLI ランタイム：HagiCode Core では、Pi は共有 libs ランタイムの上の薄いアダプターとして統合されており、プロダクト向けの安定した契約を保ちつつ、基盤の CLI プロセス処理を共通のプロバイダー層に委ねています。

セッション対応の実行：Pi は永続化されたセッション状態を再利用することも、完全にステートレスなモードで動かすこともできます。そのため長時間の開発スレッドにも、持ち越し状態が望ましくないクリーンなワンショットタスクにも適しています。

ストリーミングとツール対応のレスポンス：Pi はストリーミング出力、ツール呼び出し、システムメッセージをサポートします。単なる放りっぱなしのプロンプトラッパーではなく、対話的な実行を必要とするより豊かな AI プログラミングワークフローに参加できます。

プロバイダーとワークフローのエコシステム

Pi のエコシステムの価値は柔軟性と composability から生まれます：

プロバイダールーティングに適した設計：Pi はモデルルーティングが独立した層として扱われる環境に自然に適合します。一つのインタラクション面を保ちつつ、異なる上流のモデルプロバイダーを試したいチームに特に有用です。

セカンダリモデル選択のサポート：HagiCode Core では、Pi はプライマリの職業でプロバイダーランタイムを保ちつつ、モデル選択はモデルスロットで設定可能なままです。この分離は、CLI の振る舞いとモデルの選択を意図的に切り離すワークフローを反映しています。

統一された監視と発見：Pi は独自の実行可能ファイルの発見経路とヘルスチェックを持つファーストクラスの監視対象 CLI として扱われ、孤立したターミナルコマンドとしてではなく、より広いマルチエージェントワークステーションの一部として運用しやすくなっています。

マルチスレッド並列：Pi に複数の制御されたコーディングレーンを一度に実行させる

Pi は一つのセッションの中で多くのことをこなせますが、実際の納品は一つのタスクずつ行われることはほとんどありません。

HagiCode は複数の Pi セッションを並列実行でき、それぞれが隔離されたコンテキスト、明確な責任の境界、独立した進捗を持ちます。

これにより、Pi は設定可能なシングルスレッドの CLI から、チームが実際にソフトウェアを構築する方法に合った並列エンジニアリングワークベンチへと変わります。

• スレッド A はバックエンドの API エンドポイントをブラッシュアップ;
• スレッド B はフロントエンドのコンポーネントをリファクタリング;
• スレッド C はユニットテストを記述;
• スレッド D はセキュリティ脆弱性のコード監査を実施。

OpenSpec 提案セッション：Pi のプロバイダーとモデルの選択を追跡可能な意思決定に結びつける

日常の開発で最もよくある混乱は、コードが書けないことではなく、あれこれ変更した結果、なぜ変更したのか、何を変更したのか、変更同士がどう関連しているのかを忘れてしまうことです。

HagiCode に組み込まれた OpenSpec 提案ワークフローは、この問題を根本から解決します。すべての開発タスクは提案として起動されます：

この「まず考えてから動く」アプローチは、Pi の柔軟なルーティングモデルを文書化する場所を与えます。何ヶ月経っても、何が変わったかだけでなく、なぜ特定のプロバイダーやモデルルート、ツール境界が選ばれたのかを後から見られます。

• まず、このタスクがどんな問題を解決するのか、なぜこの方法が理にかなっているのかを書き出します;
• 提案の枠組みの中で Pi と技術方針を深く議論します。すべての会話と意思決定は提案の文脈に記録されます;
• 方針が確定したら、Pi は提案の制約の中でコードを実装します;
• 最終的な提案ドキュメント、議論の記録、コード変更が完全な追跡チェーンを形成します。

AI コミット：Pi の出力をクリーンなコミット履歴に変える

コードを書き終えた後にコミットメッセージを書くのは、多くの開発者にとって精神的な摩擦になります。雑に書けば後で重要なコミットを見つけられず、きっちり書けば時間の無駄に感じます。

HagiCode の AI コミット機能はこれを完全に Pi に任せます。コードの変更を分析し、意図と影響範囲を理解した上で、構造が明確で意味的に正確なコミットメッセージを自動生成します。さらに重要なことに、AI コミット中は HagiCode がリポジトリを自動的にロックし、並行操作による状態の衝突を防ぎ、安全で信頼できるコミットを実現します。

注意力は創造のためにとっておき、コミットの事務作業は Pi に任せましょう。

Code Server ブラウザエディタ：Pi の分析から直接編集へジャンプ

Pi がコードを分析し、問題のあるファイルを特定し、該当行まで示してくれた後、おなじみの気まずい瞬間が訪れます。AI の対話ウィンドウを離れ、IDE に戻り、またファイルを探し、手動で正しい位置までジャンプしなければなりません。この分析から編集への文脈の断絶は、流れを中断するだけでなく、AI の価値を「問題の場所を教える」止まりにしてしまい、「直接編集モードに入るのを助ける」まで届きません。

HagiCode に組み込まれた Code Server ベースのブラウザエディタは、まさにこの断絶を解消するために設計されています：

Code Server の統合により、HagiCode はコードを分析できるフロントエンドページにとどまらず、Pi の分析が直接編集アクションとして着地する完全なワークステーションになります。AI 分析と実際の編集のあいだのツール切り替えコストを最小化します。

• 分析から編集へワンクリック：Pi が提案の中で変更が必要なファイルを特定したら、HagiCode はそのファイルをワークベンチで直接開いて編集できます。ツールを切り替えたりファイルを再検索したりする必要はありません。
• ローカル、コンテナ、リモートを完全カバー：プロジェクトがローカルマシン、Docker コンテナ、リモートサーバーのいずれで動いていても、HagiCode の Code Server はブラウザからプロジェクトディレクトリを開いて編集できます。
• Vault の直接編集：Pi が関連するサンプルを指し示した際、Vault に登録したコード参照ライブラリや学習プロジェクトも Code Server から直接開いて閲覧できます。

Preset Task：Pi のワークフローを再利用可能なコマンドの青写真にパッケージ

Pi の柔軟性は強力ですが、同じプロバイダーの選択、ツール境界、タスクの枠組みを毎回手作業で言い直すのは無駄です。

HagiCode の Preset Task 機構は、こうした繰り返しのパターンを再利用可能なテンプレートに変えます。単なるショートカットコマンドではなく、拡張可能な Skills 統合プラットフォームです：

Preset Task は、Pi との協業を「毎回ワークフローを組み立て直す」ものから「用意されたワークフローを選んで実行する」ものへとアップグレードします。これこそが、設定可能性が真の運用上のレバレッジになる場所です。

• すぐ使えるコミュニティ Skills：レビュー、リファクタリング、CRUD、ドキュメントの実証されたワークフローを、毎回ゼロから組み立て直すのではなくインポートして使えます。
• 拡張可能な Skills システム：共有テンプレートを、自分のチームの規約、ルーティングのデフォルト、コーディング規約に適合させられます。
• 視覚的な操作、ターミナルの簿記ではなく：すべてを CLI の反復習慣にエンコードするのではなく、専用のインターフェースでタスクを選び、パラメータを切り替え、実行順序を並べ替えられます。

ゲーム化インターフェース：Pi のプロバイダーのツマミを可視化し親しみやすく

プログラミング自体は退屈にもなりますが、楽しくもなれます。HagiCode のゲーム化されたインターフェース設計は、コマンドラインツールの冷たい体験から脱却します：

Pi が制御を、HagiCode が体験を提供する。両者が組み合わさることで、高度に設定可能な CLI を、人々が毎日実際に楽しく操作できるワークスペースへと変えます。

• 明確な視覚的フィードバック：ターミナル出力を掘り返さなくても、セッションの状態、進捗、結果が見えます。
• 達成と進捗の可視化：コミット、提案のマイルストーン、納品のチェックポイントが、見えない背景状態ではなく、目に見えるリズムの目印になります。
• より低い運用摩擦：ターミナル純粋主義者でない開発者でも、ずっと親しみやすいインターフェース層を通じて Pi の制御モデルの恩恵を受けられます。

Agents 管理：複数の Pi セッションを管理可能な Agent フリートに

並列セッションは便利ですが、複数同時に動かすようになると、次は連携がボトルネックになります。

HagiCode の Agents 管理層は、各 Pi ワーカーを、可視のステータス、割り当てられたスコープ、独立した設定を持つ名前付きでスケジュール可能な Agent に変えます。

「たくさんのターミナルが開いている」状態から「小さな AI チームを一カ所で連携している」状態へと移行します。

• Agent のアイデンティティとステータスの可視化：どの Agent が実行中か、待機中か、ブロックされているか、アーカイブ可能かを一目で確認できます。
• タスクと Agent のバインディング：提案、レビュー、リファクタリング、テスト作業をそれぞれ専用の Agent に割り当てられます。
• 独立した Agent 設定：異なる Agent が、互いに干渉することなく異なるモデルルート、Skills、ツール露出ルール、コンテキスト範囲を使用できます。

Monospecs マルチリポジトリ管理：Pi に必要なリポジトリの地図を与える

実際のプロジェクトでは、コードが単一のリポジトリに収まることは稀です。フロントエンド、バックエンド、ドキュメント、共有ライブラリは異なるリポジトリに分散しており、一つの機能変更で複数のリポジトリを同時に触る必要が生じることもあります。Pi にとってシングルリポジトリモードは機能しますが、リポジトリ間の関係を本来は理解しておらず、毎回の会話で「この変更はあと 2 つのリポジトリにも同期が必要」と手動で伝えなければならず、明らかに非効率です。

HagiCode の Monospecs 機構は、マルチリポジトリシナリオのために設計された構造化されたソリューションです。.hagicode/monospecs.yaml 設定ファイルを通じて、プロジェクト群のすべてのサブリポジトリのアドレス、名前、関係を宣言し、提案を起動する際に Pi に自動的にリポジトリ間の地図を提供します：

Monospecs は実質的に、リポジトリをまたぐ協業における Pi の認知の死角を取り除きます。Pi のルーティングの柔軟性は、変更面の全体も見えるようになると、さらに重要になります。

• 自動的なリポジトリ関係の認識：開発提案を作成する際、Pi は Monospecs 設定からサブリポジトリ一覧を直接読み取れ、繰り返しの手動説明に頼る必要はありません。
• リポジトリ間の変更追跡：仕様は一カ所に集約され、コード変更は関連するリポジトリに留まり、意思決定履歴と実装をきれいに分離します。
• AI コミットの賢い送り先判定：HagiCode は変更内容を Monospecs 設定と照らして、各コミットがどこに属するかを提案します。
• リポジトリごとの AGENTS.md：Pi は異なるコードベースを操作する際、リポジトリ固有の規約を自動的に取得します。

Vault クロスプロジェクトのナレッジベース：Pi にターミナルの一回以上を記憶させる

Pi のセッション制御は有用ですが、永続的なセッションであっても、永続的なクロスプロジェクトの記憶層とは同じではありません。それがなければ、重要なコンテキストを依然として頻繁に再導入しなければなりません。

Vault は HagiCode のクロスプロジェクトな永続ナレッジ層です。中核の設計思想は「一度登録すれば、どこでも再利用」です：

Monospecs が Pi にプロジェクトがどこにあるかを理解させるものだとすれば、Vault は Pi にあなたが既に蓄積したものを覚えさせます。これが、設定可能な CLI をより長期的なエンジニアリングパートナーに変えるものです。

• 複数タイプのナレッジコンテナ：フォルダ、コード参照プロジェクト、Obsidian ノート、システム管理のプロンプト資産を一カ所に登録できます。
• 自動的な AI コンテキスト注入：新しい提案は、Pi に適切な参照資料が既に利用可能な状態で始まります。
• きめ細かいアクセス制御：読み取り専用の参照と編集可能なプロジェクト空間を分離し、Pi が誤ったものを変更せずに広く学べるようにします。
• クロスプロジェクトのナレッジ再利用：一度捕捉したパターンは、ゼロから組み立て直すことなく、その後のすべての提案を支えられます。

OmniRoute モデルルーティング：Pi のプロバイダーファースト設計をスケールさせて使う

Pi は既にワークフローとプロバイダー選択のより切り離された関係を奨励していますが、より大きなチームでは、そのルーティングをきれいに管理する中央の場所が依然として必要です。

OmniRoute はインタラクション層とモデルルーティング層を分離し、HagiCode はワークフローに Pi を残したまま、その下でモデルソースを切り替えられます。

これにより、より良いコスト管理、より良いタスクとモデルの適合、そしてモデルの価格や可用性が変化した際のワークフローの混乱の減少が得られます。

• 既に好みの CLI やインタラクションスタイルを維持しつつ、その下のモデルルートだけを変更できます。
• 一つのルーティング戦略を、HagiCode に接続された複数の Agent と複数の AI ツールで共有できます。
• 迅速なコーディング、深いレビュー、アーキテクチャ計画など、異なるワークロードに異なるモデルルートを調整できます。
• 個々のワークフローを作り直すのではなく、ルーティング層で一度コストと能力を調整できます。