0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

個人開発で ChatGPT Apps SDK を試してみた #2: assistant が想定と違うレスを返す問題への対応

0
Last updated at Posted at 2026-05-22

はじめに

前回は、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 を利用しながら応答を生成している仕組み

のことを指しています。

Apps SDK では、この assistant が:

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

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

参考:

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

API → JSON → frontend が描画

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

一方 Apps SDK では、

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

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

そのため、

  • tool description:ツールの説明文
  • field naming:フィールド名でassistantに意味を理解してもらう
  • structuredContent:説明分をassistantに渡すことを目的としたフィールド

などによって 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 を「表示素材」ではなく「表示結果」に近づける

例えば、以前は:

{
  "title": "2026/05",
  "count": 24
}

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

現在は:

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

のように、

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

方向に寄せています。

また、

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

のように content もかなり短くしています。

これにより、

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

などの発生率はかなり下がりました。

ただし、現時点でも他の理由でツールの説明文章を変えることで
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」寄りの調整が必要になる印象でした。

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?