自作のエージェントフレームワーク Shikigami Framework と そのMCPサーバ化について (フル)

Transcript

1. 自作のエージェントフレームワーク Shikigami Framework と そのMCPサーバ化について (Full) 2025/05/15 @masachaco
2. Clineが便利 自動でコーディングしてくれる わからないことをやらせるより 「わかりきったこと」 を爆速で行うことができて 個人的には便利
3. Clineが便利 • 進捗の変化が一目瞭然 • 一人だと大変だった作業もできる ようになった • ドキュメントを充実させる • docコメントを全て書く • テストコードの充実 Clineが出てから
4. Clineが便利 • 家に居すぎてしまう • 進捗がバンバン出るので家でつ きっきりになってしまう • 外に出たい • 季節的にちょうどいいので公園で お花見をしながらプログラミング したい • 競馬場で興味ないレース中は 暇だからプログラミングしたい • Clineはリモートでは使いづらい
5. Clineが便利 • GitHub上のプルリクで指示を出し • GitHubActions上でエージェントを 実行 • コードを生成させて • レビュー&追加指示を出す ①外から指示を出す ②GH上で指示・コード生成 ③コードレビュー
6. Shikigami Agent Framework
7. 陰陽師が お札に指示を書き 式神を使役し 課題を解決
8. エンジニアが スマホで指示を出し LLMを使役し 課題を解決
9. プログラマが スマホで指示を出し LLMを使役し 課題を解決 陰陽師と エンジニア って同じだったんだ！
10. Shikigami Agent Framework User Interface Adapter LLM User User Interface ShikigamiAgent LLM Client Shikigamiの構造 ユーザとユーザの間に共通化したUI のアダプタを用意 • 各種UIを切り替えられる • Slack • Mattermost • GitHub (プルリク) • 標準入出力 エージェントとLLMの間に、切り替え 可能なLLM Clientを用意 • モデルの切り替え • モデルの呼び出し方の 切り替え Agent Team Agent Agent Agent
11. よくあるエージェントの形式 Shikigami Agent Framework User Interface Adapter LLM User Slack UI ShikigamiAgent LLM Client Shikigamiの構造 ユーザとユーザの間に共通化したUI のアダプタを用意 • 各種UIを切り替えられる • Slack • Mattermost • GitHub (プルリク) • 標準入出力 各種UIからエージェントに指示を出 す エージェントとLLMの間に、切り替え 可能なLLM Clientを用意 • モデルの切り替え • モデルの呼び出し方の 切り替え Agent Team Agent Agent Agent
12. よくあるエージェントの形式 Shikigami Agent Framework User Interface Adapter LLM User Mattermost UI ShikigamiAgent LLM Client Shikigamiの構造 ユーザとユーザの間に共通化したUI のアダプタを用意 • 各種UIを切り替えられる • Slack • Mattermost • GitHub (プルリク) • 標準入出力 各種UIからエージェントに指示を出 す エージェントとLLMの間に、切り替え 可能なLLM Clientを用意 • モデルの切り替え • モデルの呼び出し方の 切り替え Agent Team Agent Agent Agent
13. よくあるエージェントの形式 Shikigami Agent Framework User Interface Adapter LLM User Standard IO UI ShikigamiAgent LLM Client Shikigamiの構造 ユーザとユーザの間に共通化したUI のアダプタを用意 • 各種UIを切り替えられる • Slack • Mattermost • GitHub (プルリク) • 標準入出力 各種UIからエージェントに指示を出 す エージェントとLLMの間に、切り替え 可能なLLM Clientを用意 • モデルの切り替え • モデルの呼び出し方の 切り替え Agent Team Agent Agent Agent
14. Shikigami Agent Framework User Interface Adapter LLM User User Interface ShikigamiAgent Open LLM Client Shikigamiの構造 ユーザとユーザの間に共通化したUI のアダプタを用意 • 各種UIを切り替えられる • Slack • Mattermost • GitHub (プルリク) • 標準入出力 各種UIからエージェントに指示を出 す エージェントとLLMの間に、切り替え 可能なLLM Clientを用意 • モデルの切り替え • モデルの呼び出し方の 切り替え Agent Team Agent Agent Agent
15. Shikigami Agent Framework User Interface Adapter LLM User User Interface ShikigamiAgent Claude Client Shikigamiの構造 ユーザとユーザの間に共通化したUI のアダプタを用意 • 各種UIを切り替えられる • Slack • Mattermost • GitHub (プルリク) • 標準入出力 各種UIからエージェントに指示を出 す エージェントとLLMの間に、切り替え 可能なLLM Clientを用意 • モデルの切り替え • モデルの呼び出し方の 切り替え Agent Team Agent Agent Agent
16. Shikigami Agent Framework User Interface Adapter LLM User User Interface ShikigamiAgent Gemini Client Shikigamiの構造 ユーザとユーザの間に共通化したUI のアダプタを用意 • 各種UIを切り替えられる • Slack • Mattermost • GitHub (プルリク) • 標準入出力 各種UIからエージェントに指示を出 す エージェントとLLMの間に、切り替え 可能なLLM Clientを用意 • モデルの切り替え • モデルの呼び出し方の 切り替え Agent Team Agent Agent Agent
17. よくあるエージェントの形式 Shikigami Agent Framework User Interface Adapter LLM User User Interface ShikigamiAgent LLM Client Shikigamiの構造 ユーザとユーザの間に共通化したUI のアダプタを用意 • 各種UIを切り替えられる • Slack • Mattermost • GitHub (プルリク) • 標準入出力 各種UIからエージェントに指示を出 す エージェントとLLMの間に、切り替え 可能なLLM Clientを用意 • モデルの切り替え • モデルの呼び出し方の 切り替え チームに エージェント (機能・役割)を 追加していく Agent Team Agent Agent Agent
18. 利用イメージ
19. 利用イメージ • 「Team」で定義してエージェントの 集団を表現
20. 利用イメージ • システムプロンプト (エージェントが守る前提・ルール)
21. 利用イメージ • プロンプト エージェントに依頼する指示
22. 利用イメージ • エージェントの実行
23. エージェント実装例
24. エージェント実装例 • 「AgentBase」を継承したクラスを作る
25. エージェント実装例 • 「@function_calling」デコレータを 指定してエージェントが呼び出せる 機能を表現 • 引数の型アノテーションを指定し 入力してほしい型をLLMに伝える • Pydocコメントを書いて どのような機能か どのような引数かをLLMに伝える
26. デコレータ？ 「@(好きな名前)」で関数をデコレーション できる機能。 デコレータをつけた 関数が読み込まれたときに １度だけデコレータで定義した 処理が実行される (関数の実行時ではない) この例だと、Programmer クラスが Importされた際に「read_file」処理に対して 「function_calling」の処理が1度だけ 実行される この仕組みを使って エージェントのインスタンスを作る前に 「LLMが呼び出せる機能ですよ」という マークを付けられるようにする
27. function_calling このデコレータをつけた関数(f) に対して 「_is_function_calling」 フラグを追加してTrueにする。 という処理が実行される。 これで、「@function_calling」をつけた 関数は「LLMが実行できる関数」という マークキングをすることができた
28. エージェントの準備 関数は「LLMが実行できる関数」に 印をつけることができたので エージェントのインスタンス作成時に 「LLMが呼び出せる関数の一覧」を とりまとめておく処理を実行する 具体的には「AgentBase」の コンストラクタで 「LLMが呼び出せる関数の一覧」と 「LLMが呼び出せる関数への参照の一覧」を あらかじめ作っておく これで、 「LLMはこんな処理呼び出せますよ」 「LLMが処理を呼んだらこの参照を実行し て」 という準備ができる
29. 関数一覧の作成 エージェントが呼べる関数の一覧を作る エージェントが呼べる関数は 「_is_function_calling」がTrueの関数 その関数の参照を取得する
30. 関数一覧の作成 エージェントが呼べる関数の一覧を作る エージェントが呼べる関数は 「_is_function_calling」がTrueの関数 その関数の参照を取得する Pythonの関数は、関数に定義されている 引数名や、引数の型を取得することが できる
31. 関数一覧の作成 エージェントが呼べる関数の一覧を作る エージェントが呼べる関数は 「_is_function_calling」がTrueの関数 その関数の参照を取得する Pythonの関数は、関数に定義されている 引数名や、引数の型を取得することが できる また、関数に設定されているpydocコメント も取得することができる この引数情報とコメントを整理して LLMに 「どんな関数があって」 「どんな引数があると実行できるよ」 ということを伝える
32. 関数一覧の作成 この引数情報とコメントを整理して LLMに 「どんな関数があって」 「どんな引数があると実行できるよ」 ということを伝えてておいて LLMに 課題を解決する関数と引数を指定させる 仕組みを 「Function Calling」や「Tool Use」という。 OpenLLMでは「FunctionCalling」という名前 Anthropic(Claude)では「Tool Use」
33. LLMに関数の定義を送る例 こんな感じのJSONでLLMに 「こういう機能を私は持ってます！」 と伝える Nameに実行できる関数名 Descriptionにその関数の説明 Parametersに、引数の説明が書かれている Function Callingはプロンプトとは別に JSONで指定できる テキストで指定するのではなく JSONで指定することになる
34. LLMが関数実行を指示する 例 こんな感じのJSONでLLMが 「この機能を使って！」と伝えてくる Nameに実行する関数名 Argumentsに実行する関数に指定する引数 が書かれている ArgumentsはJSONの文字列になっているので パースするとdict形式のオブジェクト にできる ので、この例だと 「get_weather」関数を 「location=“東京”」の引数で 実行できるようになる。
35. Agentで関数実行する例 実装されている変数名と function callingでLLMが指定する変数名は 一致しているので 可変長引数 (**kwarg) で まるっとマッチさせることができる このkeyと一致する引数に このvalueを指定してねということが できる ので、あらかじめ用意した関数の参照に 可変長引数でLLMが指定した変数を動的に 指定できる LLMが指定した呼び出しを そのまま関数実行に変換できる
36. ここまでのまとめ Agentのインスタンスはそれぞれ 「私こんな関数を実行できます」 「その関数の参照はこれです！」 という情報をもっており Shikigamiは、それぞれのAgentの情報を 集約する。 その後、ShikigamiはLLMに 「すんません、私こんな機能実行できるんです けど、次何したらいいですかね！」 と聞きに行く LLMは「それならら、次この機能実行して～」 と言うので、それを実行する その繰り返しで、自律的に与えられた問題を解 決するのがAgentの大まかな仕組み Shikigami Agentを起動 Team の持っている Function Callingを集約 LLMに「こんな機能あるんですけど次何したらいいですかね？ 今の状況はこれです」と聞く LLMが「これ実行して～」と返してくる 言われた機能を実行する 処理終了 次やるべきこと を考える 処理完了 or ユーザに問い合わせが必要
37. この仕組みをベースに GitHub上でコーディングできる 仕組みを作る
38. よくあるエージェントの形式 GitHub上で動かしたい GitHubActions上で動かす プルリクの内容(作業指示)と コメント(経緯・追加指示)を読んで 作業を開始する LLMのコード出力以外(つまり発言)は 標準出力に出力する 作業が完了したらプルリクに 作業完了コメントを残す (経緯を残すことで次回の作業はその 続きから行える。) GitHubのプルリク の コメントを 読み書きする エージェント ブランチ プルリク プログラミング する エージェント 作業指示 コメント・経緯 GitHubActions コード Shikigami
39. システムプロンプト • GitHub上で動くエージェントの システムプロンプト例 • 作業の流れを明記している
40. これを動かす GitHub Actionやら なんやかんや実装して 完成！
41. issueにやりたいことを書く 今回は 「ブログが作りたいです」 という内容 外での利用を想定してるので 音声入力で指示を書く 準備ができたら「shikigami」という ラベルを付けると・・・・
42. issueにやりたいことを書く GitHubActionsが起動して
43. プルリクができる プルリク作成直後はそのまま コーディングをするActionsが自動で起動する
44. コーディングする エージェントが起動し コーディングする。 コーディングした内容はブランチにコミット 作業完了したら、プルリクにコメント追加
45. コーディングした コードが追加された。 GitHub上で変更を確認する。 指定した通り、python、flaskで ブログのモックが作られている。
46. 作業報告 受けた指示の要約と、作業報告も プルリクにコメントとして追加された。
47. 作業報告 コメントして、「shikigami」 ラベルをつけると 追加指示ができる
48. Issueの作成 プルリクの作成 Shikigami Agentの実行 作業報告 レビュー・次の指示 作業完了 作業の流れ Issueにやりたいことを書く 準備できたら「shikigami」ラベルを付ける その機能を実現するための ブランチとプルリクができる プルリクができるとAgentが実行される コードを書き、ブランチにコミット 作業内容をプルリクにコメント・報告 ユーザがレビュー 追加指示があれば、再度Agentを実行 問題なければマージ
49. 目標達成 お外でプログラミングできる環境ができた たのしい！ さくらもきれい！ どこでも進捗がでる！ が、課題もまだまだあった
50. Clineと比較したときの課題 • １回の実行料金が高い • 扱える１プログラムの長さの上限がある • LLMごとにクライアントを作るのが大変 • 編集時のエラー警告をLLMが認知できない とくに料金が高いと気軽に実行できない
51. Shikigamiの改善
52. Clineの頭いいところ① ClineはLLM利用料を安く抑えるための 努力をしている その努力の１つが 「FunctionCallingを使わない」 ということ FunctionCallingは便利 • LLMが必ず指定した形で関数を呼んでくれる • やりとりのルールが整備されている 一方で不便な面もある • 毎回関数の定義を送る必要がある • 関数の実行は１回のレスポンスで 返さないといけない Clineのシステムプロンプト 引用元：https://github.com/cline/
53. Clineの頭いいところ① LLMの利用料金は 入力したトークン(≒文字数) 出力したトークン(≒文字数) が大きいほど、お金がかかる 毎回関数の定義を送る必要がある ということは、 毎回関数定義を指定する分のお金がかかる。 ClineはFunctionCallingを使わない代わりに システムプロンプトに長々と 機能を呼びたいときは以下のXML形式で リクエストしなさい というルールを書いている システム プロンプト 関数 定義 過去の記憶 今回の指示 (入力) LLMの出力 システム プロンプト 関数 定義 過去の記憶 今回の指示 (入力) LLMの出力 ２回めのリクエスト １回めのリクエスト １ 回 目 分 の 利 用 料 金 ２ 回 目 分 の 利 用 料 金
54. Clineの頭いいところ① 長々とルールを書いても 毎回その指示は送るので結局 お金がかかるのでは？ と思うが LLMによっては、 「指定したプロンプトのキャッシュ」 ができる。 毎回その指示は送るので結局 お金がかかるのでは？ と思うが LLMによっては、 「指定したプロンプトのキャッシュ」 ができる。 Clineのシステムプロンプト 引用元：https://github.com/cline/
55. Clineの頭いいところ① キャッシュにヒットすると利用料金が 安くなる。 Claudeの場合は キャッシュへの書き込みは25%高くなるが キャッシュの読み込みは9割安くなる。 つまりシステムプロンプトのような 毎回同じことを言って守らせるルールは 超お得に実行させることができる 一方でFunctionCallingはプロンプトではない (JSONによる指定)なのでキャッシュできない (トークンは消費してお金はかかる) キャッシュや記憶の管理などを 独自に行なっている システム プロンプト 関数 定義 過去の記憶 今回の指示 (入力) LLMの出力 キャッシュ した システムプロンプト 関数定義 過去の記憶 今回の指示 (入力) LLMの出力 ２回めのリクエスト １回めのリクエスト １ 回 目 分 の 利 用 料 金 ２ 回 目 分 の 利 用 料 金
56. Clineの頭いいところ② 利用料金だけでなく FunctionCallingを使わないことで プログラミング向きのメリット が生まれている FunctionCallingは関数実行を １つのJSONで指定してくるので １回のレスポンスで返さないといけない (作ればあるかもしれないが、 FunctionCallingのレスポンスの続きを出力して のような機能や仕組みは基本的にない。) LLMには１回に出力できるテキストの 上限がある つまり、FunctionCallingでは出力できる プログラムの長さに上限がある
57. Clineの頭いいところ② FunctionCallingを使わず テキストでやりとりをすると 「前に出力した内容につながるように 続きを出力して」 といった指示ができる。 つまり、より長い内容を出力できる ※ 出力が、LLMの出力上限にひっかかって 途中で終わったかどうかは、 レスポンスの中のパラメータでわかる
58. Clineの頭いいところ③ ClineはLLMのFunctionCallingに頼らずに 独自に関数呼び出しをする定義を システムプロンプトに書いている 具体的には画像のようなXMLを指定している FunctionCallingだと LLMごとに用意したフォーマットに変換する 必要がでてくる OpenAIならOpenAIのフォーマット Anthropicなら、Anthropicのフォーマットを 用意する必要がある Clineのシステムプロンプト 引用元：https://github.com/cline/
59. Clineの頭いいところ③ FunctionCallingは OpenAIならOpenAIのフォーマット Anthropicなら、Anthropicのフォーマットを 用意する必要がある。 Function Callingを使わずに 独自定義にすると LLM側がこちらのフォーマットに 合わせてくるため クライアントの実装は基本的に テキストでやり取りをする シンプルなもの だけ用意すればいい そのため、多くのLLMに対応しやすく 新バージョンの LLMが出てもすぐに対応できる 今いちばん最適なLLMを選べる Clineのシステムプロンプト 引用元：https://github.com/cline/
60. Clineの頭いいところ③ 同じ企業のモデルでも FunctionCallingに対応してるものと してないものがあったり複雑。 マルチモーダルな4oは対応しているが 推論するo1は対応してないなどの差分がある。 画像なども読めたり、読めなかったりする。 ので、LLMへのリクエストをシンプルにして おくとモデルを増やしたときの対応が楽。 モデルの追加が楽だと処理させる 内容によっては簡易モデルに切り替えたり できる。 逆に言うと、それぞれ独自実装していると モデルを増やせば増やすだけ管理工数が増える。 とてもじゃないがCline並の モデルは管理できない。
61. デメリットもあるよ 先述のメリットもあるが LLMが間違ったXMLフォーマットで 送ってきたり指定を守らない というデメリットもある その場合はリトライしている (その分費用も嵩む) あまり優秀ではないLLMは ルールを守りきれないため コストが余計にかかる場合もある LLMがよくやる失敗１（XML以外の応答が含まれる。) == はいわかりました、以下にXMLを出力します <ter> <tdef> <tn>get_weather</tn> ….. LLMがよくやる失敗2（指定した項目がない) == <ter> <tdef> <tn>get_weather</tn> </tdef> </ter> LLMがよくやる失敗3（存在しない関数を実行しようとする) == <ter> <tdef> <tn>sonzai_shinai_func</tn> ….. LLMがよくやる失敗４（そもそもXMLではない) == はい、わかりました。ほげほげを実行します
62. Shikigami Agent Framework User Interface Adapter LLM User User Interface ShikigamiAgent LLM Client Shikigamiも対応する このようにFunctionCallingを使うか 使わないかは、現状一長一短。 ShikigamiもClineに倣って、 FunctionCallingに 依存しなくて良いようにしてみる。 「LLM Client」の部分を FunctionCallingベースのものと テキストベースのものを 選べるようにする。 Agent Team Agent Agent Agent
63. Shikigamiも対応する 画像のような感じで 使いたい機能をこういうXMLで指定して～！ と、システムプロンプトを書く。 各XMLの項目名も短めに することでできるだけ安くなる。 スペースもトークンを無駄に消費するので ほんとは削ったほうが良い。
64. Shikigamiも対応する Shikigamiがやりがちな間違いを システムプロンプトの中であらかじめ 示しておく (Few-Shotプロンプティングの応用) よくある間違いをしにくくなる。 また、特殊文字が入ってると XMLのパースに失敗するので CDATAで囲うように指示をしておく
65. Shikigamiも対応する これら Shikigamiのあり方を説明した システムプロンプト XMLで使う機能を指定してねという システムプロンプト 仕事の進め方 （プルリク読んでね、成果報告してね) を書いたシステムプロンプト ユーザ指示のシステムプロンプト を１つにマージしたものが Shikigamiのシステムプロンプトになる あとは、レスポンスをパースして Shikigamiに渡せばOK Shikigamiのあり方を説明した システムプロンプト XMLでツールを呼んでね というルールを決めた システムプロンプト 仕事の進め方を書いた システムプロンプト ユーザが追加で指示した システムプロンプト Shikigami の シ ス テ ム プ ロ ン プ ト
66. 最終的に費用は Clineより同じか少し高いくらいに 抑えることができるようになった
67. Clineの頭いいところ④ Visual Studio Codeの拡張機能として 実装されているところ。 VSCode内では言語サーバが動いており 編集したコードの警告やエラーを教えてくれる 拡張機能はVSCodeのAPI経由で その警告やエラーを取得できる また、拡張機能を書くと言語サーバが 対応するプログラミング言語を増やせる つまり、VSCodeに拡張機能をいれると Clineがエラーや警告に対応できる プログラミング言語が増える Clineが言語サーバを直接管理するよりも 柔軟に実装できかつ、VSCodeの資産も 活用できる。 コード VSCode Python 拡張機能 言語サーバ Cline 言語サーバの出す エラー警告例
68. Shikigamiも対応させる Shikigamiが動くコンテナを用意する コンテナ内でVSCodeを起動する VSCodeの拡張機能を自作して 言語サーバが出している警告やエラーを 外部に公開できるようにするREST APIをつくる Shikigamiは編集したファイルをVSCodeに 都度連絡して、言語サーバのチェック機能を 動作させるようにする VSCode コンテナ 言語サーバの 警告を返す APIを 提供する 拡張機能 言語サーバ Shikigami
69. Shikigamiも対応させる できた Pythonの拡張機能と 自作した拡張機能をインストールして VSCodeをコンテナ内で起動し VSCodeの起動とAPIの準備完了を待っているところ Shikigamiが動くコンテナなので、 コンテナの名前は「Power Spot」にした
70. 更にShikigamiをClineに習う Clineには読んだり編集してほしくない ファイルを指定する「.clineignore」がある (.gitignoreのようにファイルを指定する) Clineには共通のルールを ファイルを指定指定しておく「.clinerules」がある 書かれた内容はシステムプロンプトとして 追加で読み込まれる .shikigami_ignoreと .shikigami_rulesをつくって同様の機能を 提供できるようにした
71. PowerSpot Yorishiro (Programmer等) Yorishiro (GitHubOperator等) Team Slack / Mattermost / GitHub / Standard IO LLM Shikigami VSCode 拡張機能 LLM Client (Text Base) Ofuda (UI Adapter) Workspace 編集する ファイル shikigami_ignore Shikigami_rules 最終構成 できた せっかくなので各コンポーネントに 名前をつける • Agentのフレームワーク • Shikigami • Shikigamiの実行環境 • PowerSpot • UI のアダプタ • Ofuda • Agentクラス • Yorishiro
72. 定額で使えるようにしたい
73. 定額で使いたい Claude Proを契約している 月額17ドル定額でClaudeを利用できる ※ いっぱいリクエストしすぎるとリミットに 引っかかる 外では使えないけど、家でいる間は LLMの部分をClaude Desktopで代替できたら 安くなるのになぁ・・・・ Shikigami Agent Framework User Interface Adapter LLM (Claude Desktop) User User Interface ShikigamiAgent LLM Client Agent Team Agent Agent Agent
74. できるよ
75. MCPサーバ化する Agentでやったときのように 「私こんな関数を実行できます」 「その関数の参照はこれです！」 「すんません、私こんな機能実行できるん ですけど、次何したらいいですかね！」 をLLMに伝えるプロトコルがある それが、「Model Context Protocol」(MPC) Claude DesktopはMPCを使う側(Client) としての機能があるので MPCに対応させると、Shikigamiの 機能を呼び出させることができる UIはそのままClaudeDesktopになるため UI Adpterは使用しない MCPサーバ こんなツールが 使えるよ このツール この引数で実行して 実行したよ。 結果はこの通り
76. MCPの実装例 FastMCPを使った、MCPサーバの実装例 「@mcp.tool」というデコレータをつけると FastMCPが その関数定義とpydocを読み取って MCPのクライアント(Claude Desktop)に 「こんな関数実行できまっせ！」と 伝えてくれる この例では 指定したユーザ名にマッチしたら そのユーザが好きな、キャラを返す という処理を例として実装している ローカルで動くのでClaudeとは標準 入出力でやりとりをする
77. MCPの実装例 Claude DesktopにMCPが登録されると 入力フォーム右下に ツールマークが表示される 試しに、実行してみる。 実行すると、 ツールを使って解答を生成したことが わかる MCPはClaude以外でも対応予定 ChatGPTや、Geminiも追随していく。
78. あれ？
79. これAgentで作った仕組みといっしょでは？
80. エージェント実装例 要するにShikigamiに渡している 「@function_calling」が付けられた 関数の定義をMCPに登録していけば Claudeが実行してくれるはず
81. ShikigamiのMCPサーバ化 Shikigamiがすでに 「こういう機能があって！」 「この機能を実行する参照はこれ！」 とまとめてくれているので それを持ってきて、mcpに登録するだけ。 関数の型の指定と、Pydocのコメントが 書いてあれば同じように 「こういう機能があって！」 「この機能を実行する参照はこれ！」 とClaude Desktopに伝えてくれる デコレータは関数として 手動実行させることもできるので デコレータに関数の参照を引数にして じっこうするだけで 利用可能なMCPとして登録できる 「@mcp.tool」 デコレータを関数として 手動実行してMCPに 登録していく。 LLMが呼び出せる関数や 関数の説明はShikigamigaすでに 集めているので
82. MCPサーバ化できた あっさりできた。 簡単にShikigami用の機能をつかって 実装をClaudeDesktopが始めている 複数機能を使い分けてもりもり実装している
83. まとめ
84. まとめ お外でプログラミングする機能ができた エージェントのフレームワークが揃った Clineから学ぶことがいっぱいあった 自作フレームワークは自分好みにできる エージェントの仕組みを知っていると MCPの仕組みもわかりやすい 作り方によってはMCP化も秒でできてしまう MCP化できると定額の範囲で エージェントが使える エージェント作るの楽しい！ これであなたも陰陽師
85. おわり