そのアプリの AI、Claude に繋いだ方が強いかもしれない

Slack・Google スライド・Figma の 3 つで、アプリに内蔵された AI と、Claude にそのアプリを繋いだ場合を比べました。

---

コネクタを繋いだまま、使わずに止まっていた

Claude のコネクタは、設定画面から数クリックで接続が終わります。接続自体は済ませていたものの、そのあと何を任せればいいのかが分からず、しばらく使わないままにしていました。

同じ状態の人もいそうだと思い、普段アプリの中で AI に頼んでいた作業を、そのまま Claude 側に移してみるところから試しました。以下は Slack・Google スライド・Figma での結果です。

Slack: 同じ依頼を投げたら答えが割れた

探し物を頼んだときの振る舞いを見たかったので、Slackbot と、Slack コネクタを繋いだ Claude に同じ依頼を投げました。

依頼したのは「あるチャンネルにぶら下がったキャンバスの中から、自分が過去にコメントで投稿した Figma のリンクを探してほしい」という内容です。いつ投稿したかは覚えておらず、どんな図だったかを言葉で説明しただけの、かなり曖昧な依頼でした。

結果は割れました。Slackbot は「わかりません」と返し、Claude はリンクを 1 往復で持ってきました。探していたものと同じリンクでした。

条件を公平にしておくと、Claude 側には「何に使いたいか」の説明を 1 段落だけ足しています。探す対象の指示は両方とも同じ文面です。

差がついたのは「わからない」と言ったあと

同じ情報にアクセスできるはずなのに片方が見つけられなかったので、何が違うのかを Slack の公式ヘルプで調べました。

Slack のヘルプには、Slackbot が「わかりません」と答えたあとに新しい情報を与えないまま再試行させると、満足のいく答えを返そうとしてハルシネーションを起こしやすくなる、という趣旨の記載があります（Slackbot のレスポンスに含まれるハルシネーションの特定）。一度で諦める設計には、それなりの理由がありそうです。

権限の差でも、土台の差でもなかった

見える範囲はどちらも同じで、公開チャンネル・参加している非公開チャンネル・DM に限られます。Claude が特別に広く見ているわけではありません。

仕組みの側も同系統で、Slackbot についても MCP サーバー経由で外部アプリと連携すると公式に書かれています（Slackbot を MCP で他のアプリに接続する）。同じ土台の上で、一度で諦めるか、言い方を変えて粘るかが分かれたという話です。

Google スライド: アドインが無くてもブラウザ越しに届いた

Microsoft 365 には Claude for Microsoft 365 というアドインがあり、PowerPoint や Excel から直接 Claude を呼び出せます。Google スライドに同じものは見当たらず、しばらく諦めていました。

思い出したのが Claude in Chrome で、ブラウザごと操作してもらう方向に切り替えました。Google スライドを開いた横に Claude を出し、素材サイトで見つけた参考スライドのスクリーンショットを送って「この形をテンプレートにしてほしい」と頼むだけです。細かい配置まで含めて、そのまま作ってもらえました。

アドインやコネクタが無いことと、打ち手が無いことは別でした。ブラウザで触れるものなら、Claude in Chrome を使って操作できるかもしれないと覚えておこうと思います。

Figma: ワイヤーフレームの叩き台を描かせた

参考サイトの構成をワイヤーフレームに起こす作業は、頭を使う部分より手を動かす時間の方が長くなりがちです。構造を読み取って、Figma に箱を並べるところを Claude に渡せないか試しました。

渡したのは、参考にする既存サイトの URL と、描き先の Figma ファイルの URL だけです。レイアウトの指定はしていません。cloudpack のサイトで試したところ、下の方の要素まで拾えていて、叩き台としては手直しから始められる完成度でした。

手直ししやすいかどうかも見たかったので、レイヤー構造を開いて確認しました。オートレイアウトを組んでほしい箇所には組まれていて、意味の取れないレイヤーの入れ子や、中身より大きいフレームも見当たりませんでした。

読み取れなかったところ

うまくいかなかった部分もあります。ファーストビューやカルーセルのようなメインビジュアルは構成を正確に読み取れず、何サイトか試した範囲では、ここが一番ずれました。ワイヤーのつもりが部分的に色や太さで強弱を付けてくることもあり、渡す相手によっては、その強弱を落とす手直しが要ります。

AI が生成する UI の統一感をどう担保するかは、AIDD デザインでも扱っているテーマです。デザインシステムを先に用意して開発工数を短縮したデザインシステムの導入事例も公開しています。

Figma 純正の AI とは役割が分かれた

同じワイヤーフレームを Figma 内蔵の AI にも描かせてみましたが、欲しかったものとは別の形が出てきました。そこで、それぞれ何に向くかを考え直しました。

構造を読み取って形にするところは、Claude にコネクタで繋いだ方が速く、精度も出ました。一方、画像の加工は純正の方が手数が少なく済みます。参考にしたキャプチャから「テキストとボタンを抜いて背景だけ取り出してほしい」と頼む、Web に載せる写真に写り込んだ顔へモザイクをかける、といった作業は Figma の中で完結させた方が楽でした。

おまけ: FigJam の振り返りを Markdown に出す

KPT のように、人が手を動かして付箋に書き出す振り返りは、これからも人の仕事として残ると思っています。困っていたのは、FigJam に残った振り返りの結果を次の施策を考える材料に回しづらいことでした。

FigJam Markdown Converter というプラグインを使うと、ボードの内容をそのまま Markdown に書き出せます。多少の整形は必要ですが、読める形で出てくるので、そのまま次の検討の入力に使えました。

まとめ

3 つ試して分かったことを並べます。

• Slack では、見える範囲も土台も同じで、「わからない」と言ったあとに粘れるかどうかで結果が分かれた
• Google スライドでは、アドインが無くても Claude in Chrome でブラウザごと操作すれば届いた
• Figma では、構造を考えるのは Claude、画の手入れは純正 AI と役割が分かれた。ただしメインビジュアルの読み取りは苦手で、そこは手直しが前提

アプリの中の AI で詰まったときに、同じ依頼を Claude 側へ移してみると案外いけるかもしれません。KDDIアイレットでは、こうした検証を社内で持ち寄りながら業務への組み込み方を詰めています。AI 駆動開発の進め方についてはお気軽にご相談ください。