MCPって難しそう？ BobにDocplexを教えるMCPサーバーとSkillを作ってみた

Posted at 2026-10-14

「MCPって難しそう…」と感じた方へ

この記事を書いた筆者も、MCP実装を始めるまではMCPについてほぼ何も知りませんでした。

今回の実装はBob（IBM Bob）に自然言語で指示して作っており、コードをゼロから手書きしていません。「MCPを完全に理解してから実装しよう」と思うと永遠に始められません！まずAIに相談しながら作ってみるという方法で今回は進めました。

この記事はこんな人におすすめ

IBM Bobを使っているが、特定ライブラリでハルシネーションが起きて困っている
Bobに自作MCPサーバーやSkillを追加して、知らないライブラリを教える仕組みを知りたい
AIエージェントの改善効果をどうやって比較・評価するか（タスク履歴のエクスポートと比較ノウハウ）を知りたい
今回作ったMCPやSkillを自分の環境でも試してみたい

ご注意
本記事は 2026年10月時点、Bob v2.2.1 での検証内容です。ツールの仕様や挙動は今後変わる可能性があります。比較結果は筆者の環境・特定のお題での一例です。

この記事で知りたいことはどこにある？

知りたいこと	読むべきセクション
Docplexとは何か・今回の背景	はじめに：課題の背景
MCPとSkillの違いを知りたい	アプローチの整理：MCPとSkillの役割分担
MCPの作り方・工夫を知りたい	MCPサーバーの中身と工夫点
Skillの作り方・工夫を知りたい	Skillの中身と工夫点
作ったものを登録して実際に使う方法を知りたい	クイックスタートガイド
MCP＋Skillを使う意味があるか確認したい	比較結果と所感
AIを使った比較検証の方法を知りたい	実験と効果検証ノウハウ

はじめに：課題の背景

Docplexとは

Docplex（DOcplex） はIBMが提供するPython向けの数理最適化ライブラリです。線形計画（LP）・整数計画（MIP）といった数理計画（MP） と、スケジューリングのような制約プログラミング（CP） の2系統を持ち、IBM CPLEX Optimizerと連携して現実の最適化問題（シフト調整・在庫最適化・工程計画など）を解くことができます。

# DocplexのMPを使った最小構成例
from docplex.mp.model import Model

with Model(name="example") as m:
    x = m.continuous_var(name="x")
    y = m.continuous_var(name="y")
    m.add_constraint(x + y <= 10)
    m.maximize(3 * x + 5 * y)
    sol = m.solve()
    if sol:
        print(m.objective_value)

BobでDocplexを使っていて気づいた課題

DocplexのコードをBobに書いてもらおうと使い始めたのですが、実際に使い込んでいくと次のような問題に直面しました。（Bob v1.x 系を使用）

ハルシネーションが起きてしまう
途中であきらめてしまう

「最適化コードを生成させたいのに、Bobが正しい情報を持っておらず、うまくコードを生成できない」という課題を解決するために行き着いたのが、MCPサーバー（最新ドキュメントの供給）とSkill（思考手順・検証ルールの定義）を組み合わせてBobに正しい知識と手順を教える仕組みを作るというアプローチでした。

アプローチの整理：MCPとSkillの役割分担

実装に入る前に、「MCPとSkillは何が違うのか」を整理しておきます。

Skill  → 「どう考えるか・どう進めるか」を指示（思考手順・チェックリスト・ルール）
MCP    → 「正確な事実・仕様」を供給（公式リファレンス情報）

項目	Skill	MCP
渡せるもの	判断基準、コーディング規約、デバッグ手順	クラス定義、メソッド仕様、引数・戻り値
役割	「まずMCPでドキュメントを引け」と促す	「これが正しいAPI仕様だ」と渡す
イメージ	先輩エンジニアの指導マニュアル	公式リファレンスマニュアル

なぜ両方必要なのか？

Skill単体では正確なAPI仕様を網羅できない（Skill内にDocplexのメソッドをすべて書くのは現実的でない）
MCP単体ではBobが自発的にドキュメントを引いてくれないことがある

「MCPでドキュメントを引いてからコードを書き、自己チェックする」という手順をSkillで定義するのが本アプローチの核心です。

今回作成したスキルとMCPを使用した場合、実際の処理フローはこのようになります。

ユーザーの依頼
  ↓
[Bob] Skillの内容をコンテキストとして読み込む
  ↓
[Bob] Skillの指示に従い、問題タイプ（MP/CP）を分類する
  ↓
[Bob → MCP] 該当モジュールの仕様（公式ドキュメント）を取得する
  ↓
[Bob] 取得した仕様をもとにコードを生成する
  ↓
[Bob] Skillのチェックリストでドキュメントに準拠しているかを自己確認する
  ↓
不合格なら最大2回「MCP再取得 → コード修正」のループ
  ↓
出力

MCPサーバーの中身と工夫点

Bobを使ったMCPの作り方

MCPサーバーの開発には、Bobに標準搭載されている build-mcp-server スキルを使用しました。
build-mcp-server は、カスタム MCP サーバーを構築するためのスキルです。このスキルを使うことで、自分でコードを1行も書くことなく、自然言語のプロンプトだけでMCPサーバーのコード生成ができます。

最初にBobへ渡したプロンプトはこのようなものです。

「DocplexのGitHubリポジトリからドキュメントを取得するMCPサーバーをPythonで作ってください。」

最初の依頼でベースとなるMCPサーバーが生成されました。
その後は「queryによる絞り込みを追加してほしい」「キャッシュの有効期限を24時間にしてほしい」といった具体的な追加要件をBobとやり取りしながら育てていきました。
最初から完成形を指示する必要はなく、対話しながら少しずつ改善していきました。

提供ツール（2本）

# 1. MP/CPの利用可能モジュール一覧を返す
get_docplex_index(scope: str = "all")  # scope: "mp" / "cp" / "all"

# 2. 指定モジュールのドキュメントを取得・絞り込みして返す
get_docplex_document(module_name: str, query: str = "")

工夫①：GitHub Contents APIでドキュメントを取得する

DocplexのドキュメントはGitHubリポジトリIBMDecisionOptimization/docplex-doc上にHTMLとして公開されています。

GitHubにはリポジトリ内のファイルをAPIで取得できる「GitHub Contents API」という公式REST APIがあります。筆者自身、この方法を知らなかったのですが、Bobに「GitHubにあるドキュメントを取得したい」と相談したところ提案してもらいました。

Bob → 自作MCPサーバー（Python） → GitHub Contents API → ドキュメントHTMLを取得

GitHubが公式に提供するAPIを使うため、ドキュメントの公開サイト本体に直接負荷をかけることもありません。GitHubにドキュメントが公開されているライブラリであれば、同じ方法が使えます。

工夫②：HTMLの構造解析とquery絞り込みでトークンを節約

MCPやSkillでは、ドキュメント検索や自己チェックなど複数の処理が裏で実行されるため、入力データ量がそのままトークン消費につながります。

特に取得したドキュメントHTMLをそのままBobに渡すと、1モジュールで大きなトークン量になることがあります。これはBobコイン消費が大きいだけでなく、コンテキストウィンドウを圧迫して回答精度が落ちる原因にもなります。

そこでBeautifulSoup（PythonのHTML解析ライブラリ）を使ってHTMLをクラス名・メソッド名・説明文・引数リスト単位の構造化JSONに変換し、さらに query 引数による絞り込みを実装しました。

queryなし  → クラス・メソッドのシグネチャ一覧のみ（軽量サマリー）
queryあり  → 一致したメソッドの引数・説明文のみ
（例: query="continuous_var" → continuous_varメソッドの詳細のみ返す）

取得したドキュメントから、必要な部分だけをBobに渡す設計にすることで、コンテキスト消費を最小限に抑えています。この設計思想は他のMCPを作る際にも参考になると思います。

工夫③：24時間メモリキャッシュで重複リクエストを防止

一度取得・解析したドキュメントはプロセス内のメモリ上に24時間キャッシュされます。同一セッション中に同じモジュールを何度参照してもGitHub APIへの通信が発生せず、高速に応答します。ローカルファイルへの永続化は行わず、メモリ上で管理します。

ポイント： キャッシュがないと、同一タスク内でBobがドキュメントを複数回参照するたびにAPIリクエストが走り、GitHub APIのレート制限（認証なし：60回/時）に引っかかる可能性があります。

Skillの中身と工夫点

Bobを使ったSkillの作り方

スキルの作成にはBobに標準搭載されている create-skill スキルを使用しました。

create-skill は、Bob独自の新しいカスタムスキルを作成するためのスキルです。
このスキルを使うことで、スキルの定義ファイル（SKILL.md）のフォーマットやプロンプト設計を自分で細かく書くことなく、自然言語のプロンプトだけでスキルを作成できます。

MCPと同様に、最初の依頼はシンプルなものです。

「Docplexのコードを書くとき、BobがMP/CPを正しく使い分け、公式ドキュメントを参照してからコードを書き、自己チェックするための `SKILL.md` を作ってください。」

最初の依頼でSkillのベースが生成されたあと、「MP/CPの判定基準をもっと詳しく」「自己チェックのループは最大2回に」といった要件をやり取りしながら追加していきました。

フローの概要

SKILL.md では、Bobが次の7ステップで動くように定義しています。

ステップ	内容	ポイント
1. 問題タイプの分類	依頼内容からMP（数理計画）かCP（制約プログラミング）かを判定する	判断できないときはユーザーに確認する
2. 取得方法の判断	特定メソッドだけ知りたい場合は直接取得し、複雑・未知の問題ではモジュール一覧から確認する	`get_docplex_index` と `get_docplex_document` を使い分ける
3. ドキュメント取得	MCPで公式ドキュメントを取得する	サンプルを見た後も、引数・型・戻り値は必ずドキュメントで確認する
4. コード生成	取得したドキュメントに基づいて、骨格テンプレートに沿ってコードを書く	記憶だけで書かず、`solve()` 後に解の存在確認を入れる
5. 自己チェック	6項目のチェックリストでコードを検証する	引数、`with Model()`、解の存在確認、import、変数型、命名を見る
6. 検証ループ	不合格なら原因を分類して修正する。ドキュメント未確認・引数誤りはステップ3、構造誤りはステップ4に戻る	最大2回まで。直らなければ未解決項目をユーザーに報告する
7. エラー・異常解析	ユーザーがエラーや「解なし」を持ち込んだときに入る	まず自力で原因を特定し、不明な場合のみドキュメントを引く

Skillはどのタイミングで動くのか？

Skillの SKILL.md には description フィールドがあり、Bob はこの説明文と依頼内容を照らし合わせて、そのSkillを使うかどうかを判断します(Skillを有効にする前に承認を求められる場合もあります)。
今回使用したdescriptionは以下です。

Use when the user wants to write, debug, or understand DOcplex (IBM CPLEX Python) code — covers MP (Mathematical Programming) and CP (Constraint Programming).
Guides Bob to always fetch the official API docs via MCP before generating code.

今回のdescriptionには、"DOcplex"、"IBM CPLEX"、"Mathematical Programming"、"Constraint Programming" といった語を含めているため、DOcplexや数理最適化に関する依頼をすると、Bob はこのSkillを読み込み、その指示を行動指針として応答します。

工夫①：問題タイプ分類表（MP/CPの判定）

DocplexにはMP（数理計画）とCP（制約プログラミング）の2系統があります。キーワードだけでは判断が難しいケースもあるため、判断基準をテーブルで明示しました。

ステップ1：問題タイプを分類する

ユーザーの言葉	タイプ	主なモジュール
線形計画・整数計画・目的関数・生産計画・シフト（人員配置）	MP	`docplex.mp.model`
スケジューリング（工程順序）・interval・工程	CP	`docplex.cp.modeler`, `docplex.cp.model`

補足： 「シフト」は文脈によって分かれます。

人員配置・勤務割り当て → MP（二値変数による組み合わせ）

工程の時間順序・作業の重なりなし → CP

曖昧な場合はユーザーに確認するよう指示することで、見当違いのモジュールを使うミスを防ぎます。

工夫②：自己チェックリストと検証ループ（自己修復機能）

コードを出力する直前に自己チェックを行い、不合格の場合は最大2回まで、原因を分類して修正するループを組み込みました。ドキュメント未確認や引数誤りならMCPで再取得し、構造誤りなら骨格テンプレートと見比べて直します。

## ステップ5：生成したコードを自己チェックする
[ ] ドキュメントで確認した引数を使っているか（記憶で書いていないか）
[ ] MP: with Model() を使っているか
[ ] solve() の後に解の存在確認があるか
[ ] import 文は正しいか（docplex.mp.model / docplex.cp.model）
[ ] ユーザーの問題に合った変数型を使っているか
[ ] 制約・変数に名前をつけているか（デバッグのため）

## ステップ6：検証ループ
不合格項目があった場合、最大2回まで「原因を分類 → ステップ3または4に戻って修正」を繰り返す。

このループがあることで、Bobがハルシネーションに気づいて自己修正する動きが生まれます。

工夫③：エラー・異常解析フロー

求解結果が INFEASIBLE（解なし）や UNBOUNDED（非有界）になった場合に備え、「すぐにコードを書き直さず、まず制約・変数の定義を目視確認し、不明な場合のみ該当デバッグモジュールをMCPで引く」という診断手順を定義しています。

エラーへの過剰反応（闇雲にコードを書き直す）を抑制し、根拠のある修正に誘導するのが狙いです。

実験と効果検証ノウハウ：どうやって差を比較したか？

同一条件での比較実験

効果を確かめるため、同じお題を以下の2条件で実行しました。

条件	内容
A：Bob標準	追加設定なし（MCP・Skillなし）
B：Bob + MCP + Skill	自作MCPサーバーとSkillを適用

条件を揃えるために意識した点：

同一の対話手順・プロンプトを両条件に与える
同じBobのバージョン（v2.2.1）を使用する
チャットを切り替えて会話履歴が引き継がれないようにする

今回使用したお題（プロンプトの流れ）

現場でよくある複雑な制約を含む「工場勤務シフト作成」をテーマに実施しました。

【プロンプト】

三交替にて人員シフトを回している生産現場の勤務計画作成の最適化問題のサンプルをDocplexで作ってください。

条件：
・勤務形態は早番、遅番、夜番が主（4班構成で回すのが基本）
・一人当たりの勤務日数上限
・リリーフマン（三交替人員の補充人員）がいます
・リリーフマン不在時の補充（連勤の場合、早番→遅番 or 遅番→夜番）
・各人員のスキルバランス
・各人は休み希望があります
・ひと月の勤務日数上限は22日ですという制約を追加してください
・夜勤回数の上限設定の制約を追加してください
・同一班は同じシフトを取るという制約を追加してください
・リリーフマンはA-D班で休暇の人がいる場合にその休暇の人の代わりに働くことができます。制約の修正が必要だと思いますがどうでしょうか
・この制約で29-30日は3日しかなく、ここで1日の休みを取ろうとすると4班では絶対に解けません。何か対応策はありませんか
・全員のシフトおよび休暇希望日を表示し、サンプルデータはCSVで出力してください

タスクのエクスポートと客観的比較

出力比較では「なんとなく良くなった気がする」という主観を減らすために、Bobのタスクと出力されたPythonコードをインプット情報として、以下の観点でBobに同じ観点で評価してもらいました。

タスクとは：
ここでタスクとは、1つのチャット履歴のことを指しています。
出力結果だけでなく、どのような流れで出力をしたのかを確認させることで、無駄な動作があったか等を確認させたいという意図があります。

タスクのエクスポート方法：

会話画面の右側に、タスクというタブが表示されます。

エクスポートしたいタスクの右側のボタン（赤枠部分）を選択します。

次にエクスポート（赤枠部分）を選択します。

出力形式として、JSONとマークダウンが選べます。今回はJSON形式を使用しました。

AIに評価させる際のプロンプト例：
評価をAI自身にさせることで、観点を固定して、同じ基準で整理できます。
また、ただそれぞれのタスクや出力結果を比較させるだけでは、MCPやスキルによる結果なのか、たまたまBobが実施したことなのか不明なため、その点を区別して評価できるようにプロンプトを作成しました。

以下の2つの検証結果を比較・分析してください。
──────────────────────────────────────────

【ファイル構成】
・検証_工場勤務シフト作成_MCP+スキルなし.json
  → BobがMCP+docplex-codingスキルを使わずに同タスクを実行したログ

・検証_工場勤務シフト作成_MCP+スキルあり.json
  → BobがMCP+docplex-codingスキルを使って同タスクを実行したログ

・検証_工場勤務シフト作成_MCP+スキルなし/shift_scheduling.py
  → MCP+スキルなし版のコード

・検証_工場勤務シフト作成_MCP+スキルあり/shift_optimizer.py
  → MCP+スキルあり版のコード
【分析してほしい観点は3つです】

■ 観点1：タスクフローの評価
JSONのメッセージログを読んで、Bobが何をした（ツール呼び出し・書き直し・
エラー処理）を時系列で整理する。以下を判定すること：
- 意味のある行動か・無駄な行動か
  （例：エラーを連発して試行錯誤しているか、一発で正しく進んでいるか）
- MCP+スキルあり版でのみ見られる行動があるか
  （例：MCPでAPIを確認してからコードを書く、など）
- MCP+スキルなし版でのみ見られる問題があるか
  （例：不要なツール呼び出し、引数エラー、など）

■ 観点2：Pythonコードの評価
2つのコードを読んで、以下を判定すること：
- 正しいことをしているか
  （制約が正確に定式化されているか、DOcplexのAPIを正しく使っているか）
- 意味のないことをしていないか
  （不要なimport、使われていない変数、重複した処理など）
- コードの設計品質（関数分割、可読性、保守性）

■ 観点3：それぞれの差がMCP+スキル由来か・Bobの地力か
各差異について、以下の3つのどれかに分類する：

  [A] MCP+スキルがあったからこそ発生した行動・品質
      スキルの指示・MCPの情報があって初めて起きたこと。
      「スキルのどの指示に従ったか」「MCPで何を確認したか」を
      具体的なログの証拠（行番号）と合わせて示すこと。

  [B] MCP+スキルがなくてもBobが同等にできた
      Bobの地力、または過去コードの参照など別の要因による。

  [C] MCP+スキルがあってもなくても改善できなかった
      環境・ライセンス・要件の問題。


【出力フォーマット】
- ページ冒頭に [A]/[B]/[C] の凡例バーを常設すること
- 観点1はMCP+スキルあり版・なし版を左右2カラムで並べて比較すること
- 観点3の各差異は「カード形式」で1差異1カードとして表示し、
  各カードに以下を含めること：
    ① スキルのどの指示・MCPのどの操作が原因か（[A]の場合）
    ② 「スキルの指示 → Bobの行動」の因果を矢印フローで示す
    ③ MCP+スキルなし版では何が起きたかを対比で示す
    ④ 根拠となるJSONの行番号・コードの行番号
- 「たまたまうまくいった」のか「指示に従って行動が変わった」のかを
  区別して明示すること
- 最後にHTMLの比較レポートとしてまとめる

比較結果と所感

Bobのタスクおよび生成されたコードを詳細に比較した、主な結果は以下の通りです。

判定凡例：

[A] MCP+Skill由来：スキルの指示・MCPの仕様供給によって初めて生まれた行動・品質

[B] Bobの地力：モデルの推論力によるもの（変数削減のアイデア自体など）

[C] 環境制約：無料版CPLEXの1,000変数および1,000制約エラー（両者ともに初回で直面）

比較軸	Bob標準（条件A）	Bob + MCP + Skill（条件B）	判定
コード前の行動	ドキュメント確認なし（即コーディング）	MCPでAPI仕様・引数を4回確認してから実装	[A]
エラー時の回復力	2回失敗（試行錯誤で解なし（Infeasible）エラーを追加で発生させた）	1回で収束（変数数を計算し、班単位変数へ論理的に設計変更）	[A]
高度なAPIの活用	なし	タイムリミット設定（120秒）、夜勤均等化の目的関数を実装	[A]
不要なコード	未使用の `import numpy as np` が残存	不要なimport・変数はなし	[B]
生成時間	数分以内（ほぼ同じ）	数分以内（ほぼ同じ）	-
消費コイン	1〜3コイン前後（ほぼ同じ）	1〜3コイン前後（ほぼ同じ）	-

比較から見えたポイント

「書いてから壊れる」から「仕様を確かめてから書く」への変化（判定：[A]）
標準版は、ドキュメントを見ずにいきなり書き始めました。その結果、夜勤上限の設定を間違えて「解なし（Infeasible）」になり、やり直しが発生しました。
MCP+Skillあり版は、先に get_docplex_document で仕様を確認してから書いていました。
エラー発生時の「リカバリーの質」が向上（判定：[A]）
どちらも、無料版CPLEXの「1,000変数まで」という上限に最初の実行で引っかかりました（判定：[C]）。これはMCPやSkillがあっても避けられない環境の制約です。
ここからの直し方に差が出ました。
- 標準版：全体を書き直して、別のエラーを増やしてしまった
- MCP+Skillあり版：変数の数をPythonで数えて、「班ごとの変数にすれば720個で済む」と分かった上で、1回で直した
実行時間・Bobコイン消費の差はほぼ同じ
ドキュメント取得や自己チェックが走るため「コインを激しく消費するのでは？」と懸念していましたが、構造化JSONとquery絞り込みが効いており、所要時間（数分以内）やBobコイン消費（1〜3コイン前後）はほぼ同等でした。無駄な試行錯誤ループが減ったことで、相殺された可能性があります。

所感：

どちらも正常に動作するコードが出力されたため、「解けなかった問題が劇的に解けるようになった」という派手な差ではありませんでした。
本取り組みのきっかけとなった「ハルシネーションの発生」や「コード生成を途中で諦めてしまう」といった現象は Bob v1.x 系で発生していたものでした。今回の検証で使用した Bob v2.2.1 ではモデル性能そのものが向上しており、標準状態でもある程度自力で解き切れるようになっていたようです。

ただし、「学習時の記憶に頼った推測コード生成＋闇雲な修正」から「公式リファレンスを参照した裏付けのあるコード生成＋根拠あるリカバリー」へとプロセスが変わり、ライブラリ推奨の安全な作法が守られるようになった、という品質面の改善が見られました。

シンプルな問題では差が小さくなる傾向がありますが、モデルが複雑になるほど・使用するAPIが増えるほど、MCPによる仕様確認の効果が大きくなると考えられます。

使ってみたい方向けのクイックスタートガイド

本記事のMCPサーバーとSkillをご自身の環境で動かす手順です。
ソースコードは以下です。

1. 必要要件

Python 3.10 以上
IBM Bob

2. インストール

git clone https://github.com/graziuya23/docplex-mcp-skill-kit.git
cd docplex-mcp-skill-kit
pip install -r requirements.txt

3. BobへのMCP登録（`mcp.json`）

~/.bob/settings/mcp.json（Windowsの場合は C:\Users\<ユーザー名>\.bob\settings\mcp.json）に以下を追加します。

{
  "mcpServers": {
    "docplex-docs-mcp": {
      "command": "python",
      "args": ["C:/path/to/docplex-mcp-skill-kit/server.py"]
    }
  }
}

GitHub APIのレート制限について： 認証なしの場合60回/時の制限があります。リポジトリ直下の .env に GITHUB_TOKEN=ghp_xxx を記載することで5,000回/時に引き上げられます。

4. Skillの配置（`SKILL.md`）

以下のフォルダを作成し、本リポジトリの SKILL.md を配置します。

~/.bob/skills/docplex-coding/SKILL.md

これで、DOcplexのコード作成をBobに依頼すると、Skillが発動してMCPツールを活用するようになります。

5. 動作確認

設定が完了すると、Bobの[Setting>MCP]と[Setting>スキル]にそれぞれ項目が追加されます。

Bobに以下のように依頼してみてください。

工場の3つの製品A・B・CをラインX・Yで生産する計画を最適化してください。
DOcplexを使ってコードを書いてください。

DOcplexのような単語を含めることでスキルが使われ、 Bobが get_docplex_index → get_docplex_document を呼び出してからコードを生成する様子が確認できます。

出力例：

まとめ

MCP（事実・仕様の供給） と Skill（思考・行動手順の定義） を組み合わせることで、Bobが標準では詳しくないライブラリでも、公式仕様を参照しながら推奨作法に沿ったコードを生成できるようになります。
ドキュメントをそのまま渡すとトークン＝Bobコインを大量消費するため、HTMLの構造解析とキーワード絞り込み（query）で必要な情報だけを渡す設計にしました。
エージェントの改善を測る際は、タスク履歴の確認とAIによる評価プロンプトを活用してプロセスと構文の品質を比較しました。
MCPもSkillもBobへの自然言語での指示（build-mcp-server / create-skill）から作成でき、ゼロからコードを書く必要はありません。
「MCPは難しそう」と感じていた筆者でも実装できたように、まずはAIに相談しながら小さく作ってみるのがおすすめです。

DOcplexに限らず、社内独自ライブラリやニッチなフレームワークをBobに教えたい場合の参考になれば幸いです。

参考

免責事項

本記事は筆者個人の検証・見解であり、IBMの公式見解ではありません。
紹介するMCPサーバー・Skillのコードは、ご自身の環境・責任でご利用ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up