【第4回】AI記事作成でMCP風ツールを整理する|AIエージェントの保存処理をツール化する

スポンサーリンク
この記事は約26分で読めます。

ローカルAIで作るマルチエージェント記事作成システム第4回。
第4回では、これまで mcp_client.py / mcp_server.py として作ってきたMCP風ツールを整理します。

加えて、第3回で増えた plan.txtdraft_1.htmlreview_1.txtvalidation_1.txtrun_summary.txt などの保存処理も、AIエージェント本体から切り離して管理しやすくします。

この回では、MCPを使って「AIが外部ツールを呼び出す」とはどういうことかを、ローカルファイル保存ツールを例に理解していきます。

第3回AI記事作成までで何ができるようになったか

第3回では、Planner AI、Writer AI、Reviewer AIの途中結果を保存し、AI記事作成の失敗原因を追跡できるようにしました。

たとえば、1回の実行ごとに次のようなファイルを保存します。

plan.txt
draft_1.html
review_1.txt
validation_1.txt
draft_2.html
review_2.txt
validation_2.txt
final_article.html
run_summary.txt

実際の実行結果でも、最終的に「OK判定後に保存」「Reviewer最終判定:OK」「Python側HTMLチェック:OK」となり、レビューと検証を通過した記事を保存できるようになりました。

途中保存でAIエージェントの動きを可視化する

ここで重要になるのが、保存処理をどこに置くかです。

第3回AI記事作成までは、保存処理を mcp_server.pymcp_client.py に分けていました。

main.py

mcp_client.py

mcp_server.py

outputフォルダへ保存

この構成は、まだ正式なMCP通信ではありません。
しかし、考え方としてはMCPに近い構成です。

つまり、AIエージェント本体である main.py が、直接ファイル保存の細かい処理を持つのではなく、保存ツールを呼び出しているという形です。

第4回AI記事作成では、このMCP風ツールを整理して、今後正式なMCP構成へ発展させやすくします。

MCPとは何かを簡単に整理する

MCPは、AIと外部ツールをつなぐための仕組みです。

ここでいう外部ツールとは、たとえば次のようなものです。

・ファイルを保存する
・ファイルを読み込む
・Web検索する
・データベースを検索する
・メールやカレンダーと連携する
・ログを保存する

AIは文章を考えたり、判断したりすることは得意です。
しかし、実際にファイルを書き込む、外部サービスへ接続する、検索結果を取得する、といった作業はツールに任せる方が安全です。

イメージとしては、次のようになります。

AIエージェント

MCP Client

MCP Server

外部ツール

今回のシステムでは、まだ正式なMCP Serverを立てているわけではありません。

ただし、構造としては次のように分けています。

main.py

mcp_client.py

mcp_server.py

ファイル保存ツール

このため、今回の段階では「MCP風ツール」と呼んでいます。

第3回AI記事作成でMCP風ツールを整理する理由

第1回AI記事作成の最小実装では、記事を1つ保存するだけでした。

しかし、第3回まで進むと、保存するファイルが増えました。

Planner AIの出力
Writer AIの初稿
Reviewer AIのレビュー
Python側HTMLチェック結果
Writer AIの修正版
最終記事
実行サマリー

これらをすべて main.py の中で直接保存すると、コードが読みにくくなります。

たとえば、main.py の役割は本来、次のような全体の流れを管理することです。

・キーワードを受け取る
・Planner AIを呼ぶ
・Writer AIを呼ぶ
・Reviewer AIを呼ぶ
・Python側チェックを行う
・OKなら保存する

一方で、ファイル保存の具体的な処理は、別の場所に切り出した方がよいです。

・フォルダを作る
・ファイル名を決める
・UTF-8で保存する
・保存結果を返す

このように、役割を分けることでコードが整理されます。

main.py
→ AIエージェント全体の流れを管理する

mcp_client.py
→ ツールを呼び出す入口

mcp_server.py
→ 実際の保存処理を実行する

現在のMCP風構成

現在の構成は、次のようになっています。

article-agent/
├ main.py
├ llm_client.py
├ validators.py
├ agents/
│ ├ planner.py
│ ├ writer.py
│ └ reviewer.py
├ mcp_client.py
├ mcp_server.py
└ output/

それぞれの役割は以下です。

ファイル役割
main.py全体の処理フローを管理する
planner.py記事設計を作成する
writer.py記事本文を作成・修正する
reviewer.py記事をレビューする
validators.pyHTMLやMarkdown混入をチェック・整形する
mcp_client.pyツール呼び出しの入口
mcp_server.py保存処理などのツール本体
output/実行結果を保存するフォルダ

この中で、第4回AI記事作成で変更を行うファイルは次の2つになります。

mcp_client.py
mcp_server.py

mcp_server.py の役割

mcp_server.py は、実際にツール処理を行う場所です。

第3回では、主にファイル保存を行っていました。

たとえば、指定されたパスにテキストを保存する関数です。

mcp_server.py

この関数は、次の処理をまとめています。

・保存先パスを受け取る
・親フォルダがなければ作る
・ファイルをUTF-8で保存する
・保存結果をdictで返す

ここで重要なのは、main.py がファイル保存の細かい処理を知らなくてよいことです。

main.py は、次のように呼び出すだけです。

これにより、保存方法を変更したくなった場合も、基本的には mcp_server.py のみを修正すれば済みます。

mcp_client.py の役割

mcp_client.py は、ツールを呼び出すための入口です。

現在は、mcp_server.py の関数をそのまま呼び出しています。

この段階では、ただの関数呼び出しに見えます。

しかし、ここに mcp_client.py を挟むことで、将来的に正式なMCP通信へ置き換えやすくなります。

現在:

mcp_client.py

Python関数として mcp_server.py を呼ぶ

将来:

MCP Client

MCP Serverへ通信してツールを呼ぶ

つまり、mcp_client.py は、今後の拡張に備えた「接続口」のような位置づけです。

第3回AI記事作成でMCP風ツールを使った保存処理の流れ

第4回AI記事作成で整理するツール

第4回では、保存処理を以下のように整理します。

save_text_file()
save_article()
save_run_summary()
read_text_file()

それぞれの役割は以下です。

ツール名役割
save_text_file()任意のテキストファイルを保存する
save_article()最終記事を保存する
save_run_summary()実行結果の概要を保存する
read_text_file()保存済みファイルを読み込む

第3回AI記事作成では保存が中心でしたが、第4回では読み込みも追加します。

なぜなら、今後は次のような処理が必要になる可能性があるからです。

・前回のレビュー結果を読み込む
・保存済みのdraftを再確認する
・過去のrun_summaryを確認する
・途中保存ファイルを別のAIに渡す

つまり、保存だけでなく、保存したものを再利用する 構成に近づけます。

第4回AI記事作成での改善後イメージ

第4回の改善後は、次のような構成になります。

main.py

mcp_client.py

mcp_server.py
├ save_text_file()
├ save_article()
├ save_run_summary()
└ read_text_file()

ここで大事なのは、main.py が「どう保存するか」ではなく、「何を保存するか」に集中できることです。

main.pyが考えること:
・planを保存する
・draftを保存する
・reviewを保存する
・validationを保存する
・final_articleを保存する

mcp_server.pyが担当すること:
・フォルダを作る
・ファイルを書き込む
・ファイルを読み込む
・結果を返す

この分離が、AIエージェントを拡張しやすくします。

第4回AI記事作成でMCP風ツールを使った保存処理の流れ

正式なMCPとの違い

ここで注意したいのは、第4回の時点ではまだ正式なMCPではないという点です。

現在は、Pythonファイル内で関数を呼んでいます。

現在:
main.py → mcp_client.py → mcp_server.py の関数呼び出し

正式なMCP構成では、MCP Serverが独立したサーバーとして動き、Clientが通信してツールを呼びます。

正式MCP:
AIアプリ

MCP Client

MCP Server

Tool

ただし、考え方は同じです。

AI本体とツール処理を分ける

第4回では、この考え方をローカル関数で処理している段階です。

正式なMCP構成

正式なMCPサーバーを使う流れは、AI記事作成プログラムが直接ファイル保存するのではなく、MCP Clientを通じてMCP Serverへ依頼し、MCP Serverが保存ツールを実行する仕組みです。

以下の図は、正式なMCPサーバーを使った場合、AI記事作成プログラムと保存処理がどのようにつながるかを表しています。

AI記事作成プログラムが、MCP Clientを通じてMCP Serverへ依頼し、MCP Serverが保存ツールを実行する処理の流れ

参考情報:正式なMCPサーバー使用例

実際にMCPサーバーを使った処理に関しては、AIエージェント入門|ローカルファイル操作AIを作る【第5週・上級編】の記事を参考にしてください。

第5回へのつながり

第4回でローカルツールを整理すると、次に進めるのは外部情報取得です。

現在のシステムにはWeb検索機能がありません。

そのため、キーワードに「最新」「2026年」「新機能」などを入れても、Gemma 4が実際にWebを検索して最新情報を取得しているわけではありません。

そこで第5回では、次のように発展させます。

Researcher AI

Web検索MCP

検索結果

Writer AI

つまり、第4回ではローカルファイル保存ツールを整理し、第5回ではWeb検索のような外部ツール連携へ進みます。

第4回AI記事作成 変更ファイル

第4回では、主に次の変更を行いました。

main.py
→ 何を保存するかを判断する

mcp_client.py
→ 保存・読み込みツールを呼び出す入口

mcp_server.py
→ 実際にファイル保存・読み込みを行う疑似MCPツール本体

以下に、第4回で変更する 3つのファイル を記載します。
これ以外のファイルは、第3回AI記事作成で使用したファイルと同じです。

mcp_server.py

mcp_client.py

main.py

第4回AI記事作成 実行結果

第4回作業ターミナル出力

UTF-8

SHIFT JIS

第4回作成記事

UTF-8

SHIFT-JIS

まとめ:MCP風ツールはAIエージェントを拡張する入口

第4回では、第3回までで使ってきた mcp_client.pymcp_server.py を整理し、MCP風ツールとしての役割を確認しました。

重要なのは、次の考え方です。

AIエージェント本体

ツール呼び出し口

ツール本体

外部処理

今回の例では、外部処理はローカルファイル保存でした。

しかし、同じ考え方を使えば、将来的に次のようなツールへ発展できます。

・ファイル読み込み
・Web検索
・データベース検索
・メール送信
・カレンダー連携
・外部API呼び出し

次回は、Researcher AIとWeb検索MCPを追加し、最新情報に対応できるマルチエージェント構成へ進めていきます。