音声原稿 02-c：MCPと組み込みツール
このパートでは、外部の道具をどこに置くか、カタログと操作を混ぜないこと、コードを読むときの組み込みツールの選び分けを扱います。ノートの、MCPの置き場所、リソースとツール、組み込みツール、一つのバグ調査、と同じ中身です。
チーム全員が使う課題管理のサーバーは、リポジトリの、ドットエムシーピージェイサン、です。クローンした人が同じツールを見ます。トークンをそのファイルに書くと、履歴に秘密が残ります。環境変数の名前だけを書き、値は各人の環境に置きます。たとえば、ギットハブトークン、という名前の参照だけです。
個人の実験、まだチームに配りたくないサーバーは、ホームのドットクロードジェイサンです。個人の指示が、ホームのドットクロードの中のクロードエムディーだからといって、実験用のサーバーも同じディレクトリの中だと思わないでください。ファイルが違います。ホームのクロード配下に、ドットエムシーピージェイサンを置いても、利用者が実験用として読む場所にはなりません。
接続すると、設定済みの全サーバーのツールが検出され、同時に並びます。共有と個人の両方を置くと、両方のツールが候補に入ります。実験用の危険な書き込みを個人設定に残したまま共有リポジトリを開くと、そのツールも選択の候補です。実験が終わったら、個人設定から外します。
標準的な課題管理のように、すでに広く使われているサーバーがあるなら、自作よりそれを使います。自作は、社内の権限や、そのチームだけの操作が必要なときまで残します。サーバーをどの機械で動かすかは、エージェントから見た契約の話ではありません。ここでの技能は、設定の置き場所と、ツールとリソースの境界です。
説明が薄い道具は、高機能でも、中身を探す組み込みの検索に負けます。モデルは、使い方の想像がつくほうを呼びます。課題を検索する、より、未完了の課題を、更新日と担当と要約の三欄で返す、本文全文は返さない、と書きます。
何があるかを知るための連打を減らすのが、リソースです。課題の要約一覧、文書の木、データベースのテーブル一覧。モデルはまずリソースを読み、必要な操作だけツールで行います。カタログをツールの戻り値として毎回引かせると、同じ一覧が履歴に積み上がります。操作、つまりコメントを書く、行を更新する、はツールのままです。カタログをツールにすると探索が増え、操作をリソースにすると、読むだけで副作用が起きたように見えます。
課題の担当を変える仕事で、最初から検索を連打すると、本文が履歴に積み上がります。先に、未完了の要約というリソースを読むと、識別子と一行だけが手に入ります。モデルは必要な識別子だけを、担当変更の引数にします。リソースが無いサーバーでは、ツールの説明に、最初の呼び出しは要約だけ、本文は識別子を指定した二回目、と書き、戻り値の側で本文を削ります。削る場所は、履歴に足す前です。モデルに読ませたあとで要約させても、全文はすでに窓を使っています。
コードを読むときの選び分けは、知りたいことに合わせます。関数名、エラーの文字列、インポートの出現は、グレップです。テストファイルのようなパスの一覧は、グロブです。中身をグロブで探すことはできません。ファイル全体を把握する、または全体を置き換えるのは、リードとライトです。最初から全部のファイルをリードしません。グレップで入口、つまりハンドラ名やルートの登録を見つけ、リードでそのファイルのインポートをたどります。
一意な関数の中身だけ変えるのは、エディットです。錨の文字列がファイル内で一意であることを要求します。一意でないと、どの出現を変えたかが不定なので、失敗させます。リターンと合計、という行が二回あると、エディットは失敗します。失敗の結果をモデルが読むので、次の手はモデルが選べます。錨を関数名まで長くするか、リードで全体を取ってライトで戻すか、です。失敗を、編集しました、に変換すると、モデルは変わっていないファイルを変更済みとして次の説明を書きます。エディットの失敗は、成功の文にしません。
ラッパー越しに使用箇所を追うときは、ラッパーが公開している名前を先に列挙し、その名前をグレップします。中身の実装名だけを探すと、公開名経由の呼び出しが漏れます。テストコマンドの実行は、バッシュです。テストファイルの場所はグロブ、落ちたアサーションの文字列はグレップです。シェルの検索をバッシュ経由で使うと、パスと行という結果の形を、自分で解析することになります。バッシュで置換コマンドを使うのは、一意だったかの検査を自分で捨てるので、エディットの失敗の代わりになりません。
返金の合計が明細と一致しない、という調査で通します。最初に全ファイルは読みません。グレップで返金と合計の出現を探し、入口のハンドラを一つに絞ります。パスの一覧が欲しいだけならグロブです。ハンドラはリードで見ます。巨大なら、関数名の行を先に取り、その範囲だけを読みます。修正が一つの関数ならエディットです。錨が二箇所なら、長くするか、リードしてライトです。テストの実行だけをバッシュにします。
このパートの判断は、こうです。共有はリポジトリの設定と環境変数、個人の実験はホームの別ファイルです。カタログはリソース、操作はツールです。標準的な連携は既存のサーバーを使います。中身はグレップ、パスはグロブ、一意な部分修正はエディット、駄目ならリードしてライトです。入口はグレップからです。
実験用のサーバーを外し忘れると、何が起きます。共有のリポジトリを開いたとき、個人設定に残った書き込みツールも、候補に並びます。モデルは説明が短くても、名前が近ければそれを呼びます。チームの課題を更新するつもりが、実験用のサーバーへコメントが書かれます。実験が終わったら個人設定から外す、は、説明を直すこととは別の操作です。共有の設定ファイルにトークンの値を書いた場合は、履歴に秘密が残るので、書くのは環境変数の名前だけに戻し、漏れた値は破棄します。
リソースが無いサーバーでの二段です。説明に、一回目は要約だけ、本文は識別子を指定した二回目、と書きます。戻り値を履歴に足す前に、一回目の本文を削ります。モデルに全文を読ませてから要約させると、全文はすでに窓を使っています。削るのは実行側です。担当変更のような副作用は、要約のリソースには置きません。読むだけで担当が変わったように見えると、モデルは確認のつもりで状態を変えます。
バグ調査の途中で道具を取り違えたときの戻り方です。呼び出し元をグロブで探しても、パスの一覧しか返りません。中身の文字列はグレップに切り替えます。エディットが、同じ行が二回ある、で失敗したら、その失敗を編集しました、に書き換えません。モデルは失敗を読むので、錨を関数名まで長くするか、全体を読んで書き戻すかを選べます。バッシュの置換は、一意だったかを検査しないので、この失敗の代わりにしません。テストの実行だけをバッシュに残し、落ちた文面の検索はグレップ、テストファイルの場所はグロブ、です。入口は、全ファイルのリードではなく、グレップからです。
標準的な課題管理を自作するかどうかは、契約で決めます。未完了の一覧、担当の変更、コメント、が広く使われているサーバーにあるなら、それを共有の設定へ置きます。自作が残るのは、社内の権限の段数や、そのチームだけの状態遷移が、既存の道具の説明では表せないときです。どちらの機械でサーバーを動かすかは、ここでの選択ではありません。エージェントから見るのは、説明と、カタログか操作か、と、秘密を環境変数に置いたか、です。
組み込みの選択を、最後に一つの症状で固定します。呼び出し元の文字列が欲しいのにグロブを使うと、パスの一覧しか返りません。中身はグレップです。エディットが同じ行の二箇所で失敗したら、編集しました、に変えません。錨を関数名まで長くするか、全体を読んで書き戻します。テストの実行だけをバッシュに残します。入口の全ファイル読みは、この症状では最初の手になりません。