日常をセンサーで記録してみたブログ

IoTの技術を使って日常をデジタルデータにして気づかなかった面白そうなことを探してみるページ。

AIエージェントをSSHで飛ばす:ローカルAI × MCPによる遠隔コード修正ワークフロー

研究開発業務でリモート計算機にSSH接続して作業している人は多いと思います。ただ、セキュリティなど制約があり、自律型コーディングAIを直接インストールできないケースがあります。

 

そこで、ローカルのAIエージェントに「リモート計算機へのSSHトンネル」をMCP(Model Context Protocol)経由で渡し、自律的なコード解析・修正を行わせる方法を紹介します。

 

手元AI × SSH踏み台のアーキテクチャ

リモート計算機側には特別なAIツールを一切インストールしません。手元のローカルマシンで動くAIエージェントに対し、「リモートのファイルを読み書きする」「リモートでコマンドを実行する」という最小限の道具(MCPブリッジ)を渡すだけです。

 

  • ローカル側: 自律型AIエージェントが思考・状況判断・コード修正方針の策定を担当

  • 接続部(MCP): ローカルの標準的なSSHクライアントをAIの「手足」としてバインド

  • リモート計算機: 通常通りSSHログインを受け付けるだけ(環境汚染ゼロ)

 

実際のデバッグ現場でのAIとの協調フロー

実際に発生した「Pythonスクリプトの検索・データ取得パイプラインが動かない」というトラブルを例に、AIへどのように指示を出して解決に導いたかの流れです。

 

  • Step 1: まず現状把握と原因究明だけを任せる(書き換え禁止)
    いきなり「直して」と丸投げするのではなく、まずはファイル構成と直近のエラーログを読ませ、「何が起きているか」「根本原因は何か」の仮説検証だけを指示します。
    AIはリモートの実機ログとコードを照らし合わせ、「外部ライブラリの仕様変更によるバックエンド不整合」と「クエリ生成ルールの過剰な絞り込み」という、実装とプロンプト両面の原因を特定しました。

  • Step 2: 修正方針の合意とピンポイント適用
    AIが提示してきた修正案(ライブラリ更新とバックエンド明示、ルール記述の微調整)を確認し、納得した段階で初めて「ファイルへの書き込み」を許可します。

  • Step 3: 非対話コマンドでの自律テスト検証
    修正後、リモート上で単体テストを実行させて正常終了を確認します。対話型メニュー(キーボード入力待ち)があるスクリプトの場合はタイムアウトするため、「非対話のテスト用関数を実行して」とテスト方法を指定するのがスムーズに進めるコツです。

 

この使い方のメリットと応用範囲

計算機本体に手を加えず、手元のAIから「リモートのシェルとエディタを遠隔操作させる」感覚で使えるため、以下のような理系・研究現場特有の課題と非常に相性が良いアプローチです。

 

  • GPUクラスタでの学習スクリプト調整: CUDA Out of Memory やデータローダーの例外発生時に、バッチサイズやテンソル形状の不整合をログから自動追跡させる

  • 環境分離された解析パイプラインの保守: 依存関係が厳密に固定された仮想環境(.venv やコンテナ)を壊さずに、最小限のパッチ適用とテストを回す

  • ログ解析から修正レポートの自動生成: トラブルシューティング完了後、何が原因でどこを変更したかの実施報告書をそのままAIに出力させて実験ノートや開発記録に残す

 

自律型AIを「コードを生成させるツール」としてだけでなく、「手元の安全な環境からリモート実機の調査・検証を代行させるエージェント」として使うことで、リモート環境でのデバッグ作業にかかる時間を大幅に圧縮できます。

 

自律型コード生成エージェントをLangGraphで開発

1. はじめに:コード生成AI開発

 

LLMにコードを書かせる際、AIとのチャット画面に「〇〇のコードを書いて」と1回投げるだけでは、以下のような壁にぶつかります。

  • 文法は合っているが、動かすと実行時エラーが出る

  • エッジケース(空データ、型違い、巨大な数値)で落ちる

  • 人間が毎回コピペしてテストし、手動で修正指示を出す手間がかかる

 

これを解決するのが、「AI自身にテストを実行させ、エラーが出たら自分で直させる」自律型コード生成エージェント です。そのフロー設計と、オーケストレーションツールとしてLangGraphを採用する方法を解説します。

 

2. 自律型コード生成のフロー設計(4段階の責務分離)

 

1つの巨大なプロンプトに「要件定義も設計もコードもテストも全部やって」と頼むと、LLMの思考がパンクしてバグが増えます。人間の開発チームと同じように 「責務の分離」 を行うフロー設計です。

Plaintext

[ユーザーの自然言語要望]
      ▼
│  Planner  │ 1. 要件定義:何を作るか、どんな例外を考慮すべきかを言語化
      ▼
│ Architect │ 2. 構造設計:ファイル構成、関数シグネチャ、テスト方針を決定
      ▼
│   Coder   │ 3. 実装:設計書に沿ってコードと自動テスト(pytest)を生成
      ▼
│  Sandbox  │ 4. 検証:安全な隔離環境(Docker)でテストを実行
  (テスト結果)
      ├── PASS ──► 【完成・成果物保存】
      └── FAIL
                    │ Debugger  │ 5. 自己治癒:エラーログを読んで修正
                         └──► [再度 Sandbox でテスト実行へ ]

なぜこの分割が効くのか?

  • Planner ⇄ Architect の分離: 「仕様の検討(何を作るか)」と「技術的な構造決定(どう作るか)」を分けることで、設計漏れを防ぎます。

  • テストファーストの思想: 実装と同時に「どうやってテストするか」を Architect と Coder に設計させることで、検証可能な成果物を作らせます。

  • 実行環境(Sandbox)の独立: AIに直接マシンを触らせず、使い捨ての Docker コンテナ内でテストを実行することで安全性を担保します。

  •  

3. LangGraph

 

従来の「直列パイプライン(A → B → C)」だけならシンプルなスクリプトでも組めますが、自律プログラミングには 「条件分岐」「ループ(巡回)」 が不可欠です。

LangGraph が自律エージェントの構築に選ばれる理由は主に3点あります。

 

① 「状態(State)」の一元管理

各エージェントは独立していますが、「現在のコード群」「テスト実行ログ」「リトライ回数」 などの共通状態を1つの State(辞書)として受け渡しながら処理を進めます。

 

② 「条件分岐エッジ(Conditional Edge)」の簡潔さ

「テストが通ったら終了」「落ちたらデバッガーへ」「最大N回失敗したら諦める」といったフロー制御を、コード数行のルーター関数で直感的に定義できます。

 

③ 自己治癒ループ(サイクリックなグラフ構造)

従来の LangChain(LCEL)などのチェーン構造は一方向の有向非巡回グラフ(DAG)が基本でしたが、LangGraph は グラフの巡回(ループ) をネイティブにサポートしているため、「デバッグ → 再テスト → デバッグ」のサイクルを極めて美しく表現できます。

 

4. まとめ

 

  • 自律型コード生成は、「Planner / Architect / Coder / Debugger」の責務分離

  • テスト実行環境(Docker)とエラーフィードバック を組み合わせることで、AI自身にバグを修正させるループが作れる。

  • LangGraph を使うことで、状態管理とループ制御を含む複雑なマルチエージェントフローをシンプルに実装できる。

 

「AIにコードを書かせる」から「AI同士で協調させて動くソフトウェアを作らせる」ステップへ進むための基本パターンです。

 

議論系AIエージェントの構築:Role / Tool / Agent 指向の設計

AIに対話や議論をさせようとすると、「単に同意するイエスマン」になるか、「正論でマウントをとってくるウザい論破bot」になりえます。

今回、「良き壁打ち相手」として動作する議論系AIエージェントを構築した。

システム設計における「責務分離の概念」「プロンプトパイプライン」の要点に絞って解説します。

1. ディベートAIの課題:なぜ「1つのLLM」では上手くいかないのか?

LLMに「私の主張に反対意見を出して」と一発で頼むと、どうしても表面的な反論や無礼な論破に陥ります。

対人議論で重要なのは「相手の論理構造を客観的に分解し、言外の前提をあぶり出し、受容した上で別の視点を提示する」という多段階の思考プロセスです。

これを単一のプロンプトで処理させると内部状態でタスクが競合するため、本システムでは3段階の「Role(役割)」に思考をパイプライン化しました。

2. 思考のパイプライン(3つのRole)

入力された主張に対し、以下の3ステップでデータを精査していきます。

[ユーザーの主張]
       │
   1. Analyzer (主張・隠れた前提の解剖)
       │  └─ JSON (結論・根拠・暗黙の前提・論理的課題)
       │
   2. Reframer (対抗論点・思考フレーム構築)
       │  └─ JSON (前提の揺さぶり・トレードオフ・代替アプローチ)
       │
   3. Responder (対話文合成)
       │  └─ テキスト (受容 ➔ 視点提示 ➔ オープンクエスチョン)
       │
[ユーザーへの返答]

Step 1: Analyzer(論理解剖)

ユーザーの出力を真に受けず、「結論 (Claim)」「根拠 (Reason)」「隠れた前提 (Implicit Assumption)」「論理的課題 (Vulnerabilities)」 に分解します。

特に「言及されていないが、論理が成り立つために暗黙のうちに仮定されている前提」を抽出するのが最大のポイントです。

Step 2: Reframer(リフレーミング)

Analyzerが引きずり出した「隠れた前提」や「論理的課題」に対し、「前提の揺さぶり」「トレードオフの提示」「条件限定(ハイブリッド案)」 の3方向から問いかけの切り口を設計します。

Step 3: Responder(応答合成)

論破を避け、認知の枠組み(Frame)を広げるため、応答文を「受容 (Acknowledge) ➔ 視点提示 (Pivot) ➔ 問いかけ (Question)」 の固定シークエンスで合成します。

3. アーキテクチャ設計:Role / Tool / Agent の分離

システムのメンテナンス性と拡張性を高めるため、概念を3つの層にカプセル化しています。

  • Role(.md):思考の定義

    「何者としてどう考えるか」を記述したMarkdownプロンプト。コードからプロンプトを完全に切り離すことで、Markdownエディタ上でプロンプトエンジニアリングに集中できる。

  • Tool(.py):実行手段

    LLM APIの呼び出し、レスポンスからのJSON抽出(ガードレール)、Web検索などの純粋な「機能」。

  • Agent(.py):実行主体

    特定領域のRoleとToolを組み合わせ、入出力を制御して自律動作するプログラム単位。

この「Role/Tool/Agent」の分離は、将来的にLangChainといった既存のフレームワークに移行する際にもそのまま移植できる汎用的な構造です。

4. 実際に動かしてみた手応え

例えば、「投資信託と個別株には優劣があり、戦略によって使い分けるべき」という主張を入力すると、以下のような思考プロセスが動きます。

  1. Analyzer: 「使い分けが必要」という主張の裏にある*「投資家が自身の戦略を明確に定義でき、管理コストを支払える」という隠れた前提*を発見。

  2. Reframer: *「初心者や多忙な投資家における学習コスト・手間というトレードオフ」*を問いかけの軸に設定。

  3. Responder: 主張に共感・受容を示した上で、「管理の手間や学習コストがメリットを上回る可能性」を優しく提示し、「初心者にとって選択基準となる要素は何か?」と問いかける。

単に「その通りですね」と同意するでもなく、「いや、初心者には投信一択です」と決めつけるでもない、相手に「次の思考」を促す良き壁打ち相手として機能させることができました。

まとめ

重いモデルをローカルで動かさずとも、軽量なLLM APIとPythonスクリプトの組み合わせで「思考の責務分離」を徹底するだけで、ここまでの対話を構築できます。

エージェント開発の本質は、複雑なフレームワークを使うことではなく「LLMにどの順番で、何を考えさせるか」というパイプライン設計にあると考える。

【LangChain】自作ツールをAIエージェントに組み込む

【LangChain】Tool登録の仕組みとLLMが関数を呼び出す(Tool Calling)内部の流れ

LangChainを使っているとよく目にする @tool デコレータ。

単に関数につけているだけに見えますが、「なぜLLMが適切なツールを選べるのか?」「チャットの文章からどうやって関数の引数を取り出しているのか?」 その裏側の仕組みは非常に洗練されています。

今回は、LangChainにおける Tool登録のメカニズム と、「ユーザーの入力 → LLMの判断 → ツール実行 → 結果の解釈」 という一連の流れを詳しく解説します。

1. Tool登録(@tool)の裏側で起きていること

Pythonの関数に @tool をつけると、LangChain内部では単なる関数から 「LLMが理解できる形式(JSON Schema)に変換されたオブジェクト」 へと拡張されます。

コード例

from langchain_core.tools import tool

@tool
def run_simulation(temp: float, pressure: float) -> str:
    """物理・熱シミュレーションを実行します。設定温度(temp: ℃)と設定圧力(pressure: kPa)を受け取ります。"""
    # (実際の処理)
    return result

このとき、LangChainは以下の3つの情報を自動的に抽出・生成しています。

  1. 関数名 (name): run_simulation

  2. 説明文 (description): docstring("""物理・熱...""")に書かれた文章

  3. 引数の型情報 (args_schema): 型ヒント(temp: float, pressure: float)から生成された JSON Schema

LLMに渡される実際のデータ(JSON Schema)

llm.bind_tools([run_simulation]) を呼び出したとき、LLM(ChatOllamaやOpenAI等)にはPythonコードそのものではなく、以下のような JSONデータ が送信されています。

{
  "name": "run_simulation",
  "description": "物理・熱シミュレーションを実行します。設定温度(temp: ℃)と設定圧力(pressure: kPa)を受け取ります。",
  "parameters": {
    "type": "object",
    "properties": {
      "temp": { "type": "number", "title": "Temp" },
      "pressure": { "type": "number", "title": "Pressure" }
    },
    "required": ["temp", "pressure"]
  }
}

💡 ポイント

LLMはプログラムを実行しているわけではなく、「自分が使えるツールの説明書(JSON)」 を読んで「どれを使うべきか」を判断しています。そのため、docstring(説明文)と型ヒントを丁寧に書くことがツール呼び出しの精度に直結します。

2. LLMがToolを呼び出して回答するまでの全体フロー

チャットのテキスト入力から最終回答が生成されるまで、やり取りは 2往復 行われます。

【1往復目:ツールの選定と引数抽出】
ユーザー: 「温度110度、圧力200kPaでシミュレーションして」
   │
   ▼
[ LLM ] (登録されたツール一覧のJSONを参照)
   │
   └─► 「run_simulation を temp=110, pressure=200 で呼び出すべき」と判断
       (テキスト回答ではなく Tool Call オブジェクトを返却)

【ローカル実行:Python側での処理】
[ Python ]
   │
   ├─► LLMからの指示に基づき run_simulation.invoke() を実行
   └─► シミュレーション結果 (JSON文字列など) を取得

【2往復目:結果の解釈と最終回答】
[ LLM ] (元々の会話 + ツール実行結果 を受け取る)
   │
   └─► 「シミュレーション結果によると、危険状態(DANGER)です...」
       (人間にわかりやすい最終文章を生成)

3. コードで辿る内部データの変化

実際にコードを動かしたとき、メッセージ(messages)がどのように変化していくかを見ていきます。

Step 1: LLMへの入力(1回目)

ユーザーからの自然言語プロンプトを HumanMessage として渡します。

messages = [
    HumanMessage(content="温度を 110 度、圧力を 200 kPa にしてシミュレーションを実行して")
]
response = llm_with_tools.invoke(messages)

Step 2: LLMからの返答(Tool Call の検知)

LLMは文章を返さず、「ツール呼び出し命令」 が入った AIMessage を返します。

# response (AIMessage) の中身
AIMessage(
    content="",  # テキスト本文は空
    tool_calls=[{
        "name": "run_simulation",
        "args": {"temp": 110.0, "pressure": 200.0}, # 文章から数値を自動抽出!
        "id": "call_12345678"                       # 呼び出し識別ID
    }]
)

Step 3: Python側でのツール実行と結果のセット

response.tool_calls が存在することを検知し、Python側で関数を実行して、その結果を ToolMessage として会話履歴に追加します。

# ツールの実行
tool_result = run_simulation.invoke(tool_call['args'])

# 履歴に追加(どの呼び出しIDに対する結果かを明記する)
messages.append(response) # AIMessage を追加
messages.append(
    ToolMessage(
        content=str(tool_result), # シミュレータから返ってきたJSONなどの結果
        tool_call_id=tool_call['id']
    )
)

この時点での messages の中身(会話履歴)は以下の3要素の配列になっています。

  1. HumanMessage: 「温度110度、圧力200kPaで〜」

  2. AIMessage: 「run_simulation(temp=110, pressure=200) を実行して」(ID: call_1234

  3. ToolMessage: 「ID: call_1234 の結果は {"status": "DANGER", ...} でした」

Step 4: 実行結果をLLMに渡して最終回答を得る(2回目)

この履歴(messages)をそのままもう一度 LLM に渡します。

final_response = llm_with_tools.invoke(messages)
print(final_response.content)

LLMは「自分が要求したツール(ID: call_1234)の実行結果(ToolMessage)が返ってきた」と認識し、その結果(DANGERや警告文)を読解して「安全ではありません。温度と圧力が閾値を超えています」 という最終的な回答を生成してくれます。

まとめ

LangChainにおける Tool Calling の核心は以下の通りです。

  1. @tool は関数を JSON Schema に変換する仕組み: LLMはコードではなく「関数の説明書(JSON)」を読んで判断している。

  2. 会話履歴(messages)をバトンリレーする: HumanMessageAIMessage(ToolCall)ToolMessage(結果) の順で履歴を構築して再度LLMに渡すことで、結果を踏まえた解釈が可能になる。

この流れさえ押さえておけば、DB検索やWeb検索、API連携など、あらゆる自作ツールをAIエージェントに組み込めるようになります!

AIChat × Ollama × Gemini で作るハイブリッドRAG環境

日常のターミナル作業の中で「ローカルのメモやドキュメントを即座にAI検索したい」と思ったことはありませんか?

今回は、軽量で高速なCLI AIツールである AIChat と、ローカルLLM実行環境 Ollama、そして高性能な Gemini API を組み合わせた快適なRAG(Retrieval-Augmented Generation:検索拡張生成)環境の魅力と実際の使い勝手をご紹介します。

💡 この構成のメリット

  1. コスト&プライバシーの最適化

    • Embedding(ベクトル化): ローカルのOllama(nomic-embed-text)で行うため、トークン費用が一切かからず大容量ドキュメントも安心。

    • 回答生成(Chat): 高精度かつ高速な Gemini API を使用。

  2. CLI完結の快適操作

    • ターミナルから一発でRAGの初期化・切り替え・検索が可能。

  3. ローカルとクラウドのいいとこ取り

    • 機密情報のベクトル化はローカルCPUで安全に行い、文章生成のみ強力なクラウドLLMに任せるハイブリッド運用を実現。

🛠 システム構成

今回活用する環境のイメージは以下の通りです。

[ ローカルドキュメント (demo.txt) ]
             │
             ▼ (ベクトル化)
 [ Ollama (nomic-embed-text) ] ── (ローカルCPU動作)
             │
             ▼ (コンテキスト抽出)
     [ AIChat CLI ]
             │
             ▼ (プロンプト + コンテキスト送信)
   [ Google Gemini API ] ──► 高精度な回答を出力!

  • OS: Linux (Ubuntu想定)

  • LLM (Chat): Gemini API

  • Embedding: Ollama (nomic-embed-text)

  • CLI Tool: AIChat

🔍 RAGインデックスの活用と検証

インデックスの作成と切り替え

AIChatでは、ターミナル上のREPLモードからシンプルなコマンドでドキュメントのベクトル化や参照の切り替えが行えます。

default) .rag my_docs

対象のドキュメント(例: demo.txt)を指定するだけで、ローカル上で一瞬にしてベクトルデータベースがアクティブになります。

動作検証:セマンティック検索の威力を試す

例えば、直接「コーヒー」という単語が含まれていないドキュメントに対して、次のように質問してみます。

Q: 「コーヒーを飲みたいときはどこに行けばいいですか?」

AIChatは内部でコンテキストを検索し、ドキュメント内の「全自動の高級エスプレッソマシン」という表記を見つけ出して、以下のように正確な回答を生成してくれます。

A: 本社の3階にあるリフレッシュスペースに行けば、全自動の高級エスプレッソマシンが設置されています。マイボトルを持参してご利用ください。

💡 根拠(ソース)の追跡も可能

回答の根拠となったファイルや該当箇所を確認したい時は、AIChat内で .sources rag と入力するだけです。

default@my_docs) .sources rag
demo.txt (0-0, 0-1)

どのドキュメントのどのチャンクを参照したのかが透明化されているため、ハルシネーション(嘘の生成)のチェックも容易です。

📝 まとめ

AIChat と Ollama を組み合わせることで、「コストゼロのローカルEmbedding」「クラウドLLMの圧倒的生成能力」 をイイトコ取りしたRAG環境が簡単に手に入ります。

ターミナル作業がメインのエンジニアにとって、自分のメモ帳や対応手順書をそのままAIナレッジ化できるこの構成は非常におすすめです。

 

【自作PC】余ったパーツを再利用!Geminiと二人三脚で組む、Ubuntu環境の実用サブマシン構築記

完成した自作PC

1. 導入:アップグレードで余ったパーツで新しいPC作成

メインPCのCPUやGPUを新しくした際、手元に残る「数世代前のパーツたち」。そのまま眠らせておくのはもったいない!ということで、これらのパーツを再利用(リユース)して、新しくサブPCを1台構築。

今回のマシンは、Linux(Ubuntu)環境での開発やちょっとした実験用。

2. 構成(スペック一覧)

「手持ちのパーツ」を活かしつつ、足りない土台部分(マザーボード、電源、ケース)を新調する構成。

  • 【再利用パーツ(手持ち)】

    • CPU: AMD Ryzen 5 5600G

    • GPU: MSI製 GeForce GTX 1660 SUPER

    • メモリ: DDR4 16GB

    • ストレージ: M.2 SSD 256GB

  • 【新規購入パーツ】

    • マザーボード: (≒10,000円, micro-ATX)

    • 電源: (≒5,000円, 650W)

    • PCケース: (≒5,000円)

3. 組み立ての相棒は「AI(Gemini)」

今回の自作で面白かったのが、「Geminiと対話しながら組み立てを進めた」点。

説明書を見ても「あれ?これどうつけるんだ?」と迷うポイントが時々あります。今回迷ったのが、M.2 SSDの取り付け部分。手持ちのパーツとマザーボードの形状が少し変わった形をしており、一瞬手が止まりました。

そこで、スマホでその部分の写真をパシャリ。そのままGeminiに見せて「これ、どうやって固定すればいい?」と相談してみました。 AIに画像を見せながら「ここはこうだよ」とリアルタイムにアドバイスをもらう感覚は、まるで頼りになるギークな友人が横にいてくれるかのよう。大きなトラブルもなく、スムーズにハードウェアを組み上げることができました。裏配線もすっきりとまとまり、エアフロー抜群の美しいビルドに仕上がっています。

4. OSインストール:Ubuntu 22.04 LTSで開発環境を構築

OSのインストールは手元にあったインストール用のUSBメモリを使い、Ubuntu 22.04 LTSを導入しました。

Ryzen 5 5600GとGTX 1660 SUPERの組み合わせは安定して動作。これからこのマシンを使って、Pythonでの開発や、様々なツールを試していく。

AI×FreeCAD自動設計の進化:MCPによるツール連携

 

AI×FreeCAD自動設計の進化

〜「コードを書かせる」から「手足を与える」へ〜

1. 以前のアプローチ:コード直接生成型(生成AI 1.0)

以前のコードでは、Geminiに直接FreeCAD用のPythonコードを「書かせて」いました。

  • 仕組み: システムプロンプトで厳格に「コードのみを出力せよ」「AppやGuiを直接使え」と教育し、出力された文字列をそのまま exec() へ流し込む方式。

  • 課題:

    • 構文エラーとの戦い: AIが「つい」Markdownの枠を付けてしまったり、存在しないAPIを捏造(ハルシネーション)したりすると即座にエラー。

    • リトライの限界: エラーが出た際にその内容をAIに突き返して「修正して」とお願いするループが必要で、効率が悪かった。

    • 職人芸: AIに正しく書かせるために、人間側が「呪文(プロンプト)」を磨き続ける必要があった。

2. MCPによるツール連携

現在の構成は、AIにコードを書かせるのではなく、AIが「あなたが定義したツール(bridge.py)」を選択して実行する方式です。

  • 仕組み: bridge.py が「手足」となり、create_boxmake_cut といった確実な関数を提供。AI(Gemini)は設計図を見て、どのタイミングでどのツールを使うべきか「推論」に専念する。

  • 進化のポイント:

    • 確実性: AIが生成するのは「コード」ではなく「ツールの名前と引数(JSON形式)」。構文エラーの概念がほぼ消えた。

    • 専門知の分離: 「どう描くか(低レイヤー)」は人間が bridge.py で定義し、「何を描くか(高レイヤー)」はAIが担当。役割分担が明確になった。

    • 自律性: マルチステップ・ループにより、AIが「次は穴あけだ」と自分で状況を判断して連続実行できる。

3. 比較表:旧・新アプローチの違い

比較項目 以前(コード生成) 現在(MCP + ツール実行)
AIの役割 コードを書く 指揮者(ツールを選ぶ)
出力形式 生のPythonコード(不安定) 構造化された実行命令(確実)
エラーの質 構文エラー、APIの誤用 物理的な配置ミス(推論のミス)
拡張性 プロンプトを増やすしかない bridge.py に関数を追加するだけ
キャリアの活用 通信知識をプロンプトに活かす 通信知識で「神経系(MCP)」を構築する

4. 結論:bridge.pyの「解像度」が設計の質を決める

以前のコードでは、AIがいかに「賢くコードを書くか」に依存していました。しかし、MCP版では「人間がいかに使いやすいツール(bridge.py)を定義するか」に重心が移っています。


 

【補足】MCP(Model Context Protocol)

MCP(Model Context Protocol) について

1. AIと外部世界を繋ぐ「共通規格」

従来、AIに特定のツール(今回の場合はFreeCAD)を操作させるには、その都度専用の連携プログラムをゼロから組み上げる必要がありました。

MCPは、「AI(知能)」と「外部ツールやデータ(手足・知識)」を繋ぐための標準的なインターフェース規格です。Anthropic社によって提唱されましたが、現在はGoogle Geminiをはじめとする主要なAIモデルでの活用が急速に広がっています。

2. なぜMCPが必要(カプセル化の恩恵)

以前の方式では、GeminiにFreeCADの内部APIを直接教え込み、コードを生成させていました。これは、いわば「脳が直接筋肉の細胞一つひとつに電気信号を送る」ようなもので、非常に不安定でした。

MCPを導入することで、以下のような役割の分離(カプセル化)が実現しました。

  • MCPサーバ (bridge.py):

    「箱を作る」「穴をあける」といった具体的な手順を定義し、AIに対して「私はこれらのツールを持っています(ListTools)」とカタログを提示します。

  • MCPクライアント (client.py):

    AIの思考結果を受け取り、サーバへ実行を命じる司令塔です。

  • AI(Gemini):

    カタログの中から今の状況に最適なツールを選び、必要なパラメータ(寸法など)を決定する「推論」に専念します。

3. 「翻訳」がいらなくなるメリット

MCPの最大の特徴は、AIがツールの使い方を自律的に理解できる点にあります。

ツールを定義する際に「これはM3のネジ穴をあけるツールです」という説明(メタデータ)を添えるだけで、AIはそれを読み取り、人間が詳細な指示を与えなくても「ネジ穴が必要ならこのツールを使えばいいんだな」と判断できるようになります。

4. まとめ:MCPがもたらした「神経系」の確立

今回のFreeCAD連携において、MCPは単なる通信プロトコルではありませんでした。それは、AIという汎用的な知能が、FreeCADという専門的な肉体を自在に操るための「神経系」そのものを構築したと言えます。

「コードを書かせる」という不安定な段階を脱し、「定義されたツールを使いこなさせる」という一段上のステージへ。MCPの導入は、AIを「チャット相手」から「実務を担うパートナー」へと変えるための、不可欠なステップです。