はじめに

前回は、ChatGPT Apps SDK と MCP（Model Context Protocol）を利用して、

ChatGPT から Miro 情報を取得する
Miro 上の議論整理を支援する

ようなツールを試作した話を書きました。

今回は、その後実際に Apps SDK 上で動かしてみて遭遇した、

assistant が想定と違うレスを返す問題

について書いていきます。

単純に API を実装すれば終わりという話ではなく、

ChatGPT が tool の結果をどう解釈するか
structuredContent がどう扱われるか
assistant がどこまで UI を「補完」しようとするか

など、かなり「AI interaction design」寄りの問題が出てきました。

シリーズ：個人開発で ChatGPT Apps SDK を試してみた

※ 本記事は ChatGPT Apps SDK / MCP を用いた個人開発・検証の記録です。内容は個人の見解であり、所属組織を代表するものではありません。

Apps SDK では assistant が tool を解釈している

今回、最初かなり混乱したのが、

「assistant がどこまで tool を解釈しているのか」

でした。

ここで言う assistant とは、

ChatGPT 内部で tool を利用しながら応答を生成している仕組み

のことを指しています。

また、ここで言う tool とは、

ChatGPT から呼び出せる外部機能
API のようなもの

を指しています。

今回のツールでは、

フレーム一覧取得
フレーム内容取得

などを tool として定義しています。

Apps SDK では、この assistant が:

どの tool を呼ぶか
どんなパラメータで呼ぶか
tool の結果をどう表示するか

などを判断しているとされています。

参考:

OpenAI Apps SDK
https://developers.openai.com/apps-sdk/

旧来からの API を利用した開発では、

API → JSON → frontend が描画

のような構成になることが多いと思います。

一方 Apps SDK では、

tool schema
↓
assistant が tool を呼び出す
↓
tool 実行
↓
assistant が戻り値を解釈
↓
応答生成

のような流れになります。

そのため、

tool description：ツールの説明文
structuredContent：assistant に渡される構造化データ
field name：構造化データの field 名

などを変更することで、assistant の挙動をチューニングする必要がありました。

今回、実装そのものよりも、この部分に時間を使いました。

実際に起きた問題

今回やりたかったこと自体はかなり単純でした。

例えば、

ボード〇〇から情報を取得して

のように依頼すると、

assistant が:

ボード内のフレーム一覧取得 API を選択
API を実行
戻り値を一覧表示

してくれるイメージです。

ここで言う「フレーム」とは、

Miro ボード内の領域
テキストや付箋を含むまとまり

のようなものを指しています。

理想としては、例えば下記のような一覧をそのまま表示してほしいと思っていました。

1. 2026/05（付箋24件） — 勉強会メモ...
2. 2026/04（付箋18件） — 振り返り...
3. 2026/03（付箋31件） — アイデア整理...

実際、API 呼び出し自体はかなり正常に動いていました。

問題だったのは、

assistant が戻り値を勝手に省略してしまう

ことでした。

例えば:

件数が消える
preview が省略される
numbering が崩れる

などが発生しました。

つまり backend 側では:

1. 2026/05（付箋24件） — ...

を返しているつもりでも、

assistant 側では:

- 2026/05
- 2026/04

のように要約されてしまうケースがありました。

もちろん、例えば毎回ユーザ側で、

Miro：〇〇ボードから情報を取得して
情報は省略しないでね

のように補足すれば、かなり改善します。

ただ、それでは使い勝手が悪いため、

assistant が勝手に省略しない

状態に持っていく必要がありました。

現在採用している対応

現在は、主に下記のような方向で調整を行っています。

visible field と internal field を分離する
structuredContent を「表示素材」ではなく「表示結果」に近づける

例えば、以前は:

{
  "selectionNumber": 1,
  "title": "2026/05",
  "count": 24,
  "preview": "勉強会メモ..."
}

のような schema にしていました。

現在は:

{
  "selectionNumber": 1,
  "userVisibleSelectionTextExact":
    "1. 2026/05（付箋24件） — 勉強会メモ..."
}

のように、

backend 側で表示用文字列を完成させる

方向に寄せています。

また最初は、assistant に返すメッセージとして、

整理したいフレームを選択してください。
Frame名を直接指定することで表示されていないFrameも指定できます。

のような説明も含めていました。

ただ、これによって assistant が長い返答を自分で組み立てるようになり、本来表示してほしい一覧情報まで省略してしまうことがありました。

そのため現在は、

番号またはFrame名で指定してください。

程度までかなり短くしています

これにより、
こちらが想定していないレベルにまでメッセージが省略されてしまう現象の
発生率はかなり下がりました。

ただし、現時点でも他の理由でツールの説明文章を変えることで
assistant の挙動が変わってしまう等の事象があり、まだ継続検証中です。

ここまで触ってみて感じたこと

今回かなり面白かったのは、

Apps SDK では schema 自体が assistant behavior に影響する

ことでした。

特に:

field naming
tool description
structuredContent

などによって assistant の挙動がかなり変わるように見えました。

また、

LLM に presentation layer を持たせすぎると不安定

というのも強く感じました。

おわりに

Apps SDK / MCP は、単純な API 連携というより、

assistant がどう解釈するか
schema がどう扱われるか
structuredContent がどう UI に影響するか

など、かなり「AI interaction design」寄りの調整が必要になる印象でした。

今後も色々検証したいことがありますので、ツールはどんどん改修していくことになるかと思います。
今後の検証結果や周囲の反応を見ながら、続きのネタは考えていきます。