記事を開いていただきありがとうございます。 今回は「遊び方を教えてくれるAIチャットボット開発」をテーマに「用例」と「システム構成」を簡単にご紹介させていただきます。 開発したAIチャットボットの紹介 ワンピースカードゲームでは、お客様に向けてルールを公開していましたが、網羅的にルールを記載しているため、お客様が確認したいルールを探すのが難しいという状況でした。 今回のチャットボットではRAGという仕組みを使い、AIチャットボットがユーザーからの入力に合せて適切にルールを回答するということを実現しました。 例えば、ワンピースカードゲームには「起動メイン」という効果があるのですが、自然

はじめに｜なぜ“AI × DesignOps”なのか？ プロダクトが成長すればするほど、ビジュアルアセットの需要は指数関数的に増えていきます。しかし、デザイナーの数は（悲しいことに）指数関数的には増えません。 従来のイラスト制作は個人のスキルに依存しやすく、結果として品質のバラツキや制作スピードが開発ベロシティを阻害する「 デザイン負債（Design Debt） 」を生み出していました。DesignOps の本質は、デザインを「一点物のマニュアルアート」から「再現可能なシステム」へと昇華させることにあります。 私たちは今回、AI を単なる「便利な魔法の筆」ではなく、一貫性のあるデザインシステムを支える「 レンダリングエンジン 」として再定義する検証を行いました。 DesignOpsとは？ 「DesignOps（デザインオプス）」という言葉、デザイナー以外にはまだ少し耳慣れないかもしれません。 簡単に言うと、 DesignOps は 「 デザイン版の DevOps 」です。 属人的になりがちなデザイン業務をプロセスとして整理し、担当者が変わってもチームとして一定の品質をデプロイできる状態を目指す考え方です。 今回の取り組みでは、生成 AI を「クリエイティブな遊び」としてではなく、プロダクトのコードベースの一部のように運用できるかを検証しました。特にエンジニア主体の組織においては、デザインも「 ロジックとして扱えるか 」が、持続可能な運用の鍵になります。 プロジェクトの背景：Unlimited App で直面した「成長の痛み」 Unlimited App ではこれまで、プロダクトデザイナーがイラストの世界観設計から品質の最終調整まで、いわば「職人のこだわり」をもって一貫して担ってきました。しかし、プロダクトが成長し、機能追加やコンテンツ拡張が加速するなか、必要とされるイラストの量と展開範囲は、私たちの想像を超えるスピードで拡大していきました。 https://kinto-jp.com/unlimited/app/ その過程で、個人の努力だけではカバーしきれない「 構造的なボトルネック 」が浮き彫りになってきたのです。 工数の比例増加 ：表現を都度最適化する運用では、制作アセット数に比例して工数も積み上がっていく（まさに O(n) の世界です）。 再現性の設計難度 ：クオリティの判断が個人の経験値に依存しやすく、「なぜこれが正解なのか」という基準を仕組みとして残しづらい。 属人的なバランス調整 ：スピードと完成度のトレードオフを、常に個人の「さじ加減」で調整し続けなければならない。 これらは決して個人のスキルの問題ではなく、プロダクトが次のステージへ進むために解決すべき「 システム上の課題 」でした。 そこで生まれたのが、「 イラスト制作を個のスキルに依存する形から、再現性のある設計へとリファクタリングできないか？ 」という問いです。私たちはこの問いに対し、生成 AI という強力なエンジンを DesignOps のプロセスに組み込むことで、持続可能な制作体制の構築に挑みました。 ※ [ ちょこっと技術解説 ]： O(n) とは？ エンジニアがよく使う「計算量」を測る指標です。ここでは「描くイラストの枚数（ n ）」が増える分だけ、「制作時間」も正直に増えていくという 線形の現実 を指しています。 つまり、「 単なる「魔法」ではなく、10 倍の依頼が来たら 10 倍の工数が必要になる 」という、デザイナーにとっては少し切ない、そしてエンジニアにとっては「今すぐ最適化（リファクタリング）したい！」と血が騒ぐ状態のことです。 今回の検証アプローチ｜“AIに寄せる” vs “AIを寄せる” AI を活用する際、戦略は大きく 2 つに分かれます： AI に寄せる（AI-Native Approach） AI が得意な表現（原生スタイル）をそのまま受け入れ、効率を最大化する。「AI っぽさ」を味方につける手法です。 AI を寄せる（Brand-Centric Approach） 独自のブランドアイデンティティに基づき、AI の出力を厳格に制御する。 Unlimited App はすでに確立された世界観を持つプロダクトです。そのため、前提条件として「AI を寄せる」 アプローチを選択しました。これは、プロンプトを単なる命令文ではなく、ブランドの 「デザイン・トークン（Design Tokens）」 として定義し、AI という不確実な実行環境において 「決定論的な出力（Deterministic Output）」を目指す、エンジニアリング的な挑戦でもあります。 イラスト標準化の設計思想とプロンプトアーキテクチャ 「AI なら、プロンプトひとつで何でも描いてくれるのでは？」——そんな期待は、運用フェーズに入った瞬間に崩れ去ります。実用的な DesignOps において、プロンプトは単なる「魔法の呪文」ではありません。明確な設計意図を AI へ伝えるための、厳密な「 インターフェース 」であるべきです。 標準化プロセスの構築にあたり、筆者は下図のような 7つのステップ を策定しました。ビジュアル定義の抽出（Step 1）からリファレンスの整理（Step 4）までは、いわば「 視覚的な仕様書 （ Visual Spec ）」を書き上げる、設計の根幹を支えるフェーズです。 Step 1〜4：プロンプトを「エンジニアリング」するための前処理 Step 1｜ビジュアル定義の抽出（Extracting Visual Tokens） 最初に取り組んだのは、デザインシステムとの整合性チェックです。2.5D の立体感、余白の持たせ方、低コントラストな配色……。これらを言語化する工程は、後に解説する 「 Style Tokens （ スタイル定数 ）」 の基盤となります。 Step 2｜イラスト用途の分類（Defining the Scope） 生成 AI の活用範囲を「クリエイティブな表現」ではなく、「 UX を補助するインフォグラフィック 」 と定義しました。目的を限定することで、維持すべき「再現性」と、AI に任せるべき「表現幅」の境界線が明確になります。 Step 3 & 4｜リファレンスの構造解体（Deconstructing References） 大量のリファレンスを収集し、「好き嫌い」という感性ではなく、構図や影の強度といった「 Visual Spec（視覚仕様） 」として分解・整理しました。「なんとなく似ている」を「仕様通りである」に変えるための、最も泥臭く、かつ重要なリサーチ工程です。 この Step 1〜4 の本質は、「 AI に依存しない設計構造を人間側で作る 」 ことにあります。 このプロセスで最もエキサイティングであり、かつ重要なのが Step 5 の「プロンプト作成」 です。ここを単なる「作文」にせず、 エンジニアリング的に構造化された工程 として設計しました。 具体的には、プロンプトを以下の 2 層構造（Layered Architecture） として定義しています： Part 1：Style Tokens（スタイル定数層） 線画の太さ、立体感、陰影のルール、配色など、プロダクトの DNA を定義します。「何を描くか」に依存しない、 再利用可能な Constant（定数）レイヤー です。 Part 2：Content Variables（コンテンツ変数層） 「車」「人物」「スマホを持つ手」など、画面ごとに差し替え可能な Dynamic Variable（動的変数）レイヤー です。 この 「 スタイルとコンテンツの解耦（Decoupling） 」 こそが、DesignOps 視点での解決策です。これにより、「何を描いても同じトーンで出力される」という、デザイナーにとっての聖杯（Holy Grail）を目指しました。 ツールごとに異なる「Prompt の最適解」 検証を進める中で面白いことが分かりました。AI ツールごとに「プロンプトの癖」が全く違うのです。以前は同一のプロンプトで比較していましたが、現在は「構造（Part 1 / Part 2）は共通、実装（実際の記述）は各ツールに最適化」 という方針に切り替えました。 「プロンプトを共有する」のではなく、 「プロンプトを設計するインターフェース（ルール）を共有する」。この方が、ツールの進化に柔軟に対応できる持続可能な仕組みになります。 徹底検証：生成 AI 3 社の「性格診断」—— イラスト標準化の最適解を探る 2025年10月時点の Midjourney 検証 まずは、2025年10月に行った Midjourney（V7）での検証結果です。 当時の出力は、視覚的な完成度が非常に高く、一枚絵としての魅力は群を抜いていました。 しかし、標準化という観点では、いくつかの課題が見えてきました。 装飾的な要素が多く、情報量がやや過剰 構図がダイナミックで、並べた際の統一感が出にくい ブランドトーンよりも「生成AIらしさ」が前面に出る傾向 つまり、 創造性は高いが、制御性が低い。 この特性はクリエイティブ用途には適していますが、UI内で量産・運用するインフォグラフィック用途には不向きであると判断しました。 ChatGPT / Gemini へのシフト Midjourney との比較を経て、検証の軸を「表現力」から「再現性」へとシフトしました。 同一のビジュアルリファレンスと構造化プロンプトを用い、ChatGPT および Gemini で出力を比較しました。 この時点で明確になったのは、 ChatGPT は構図の安定性が高い Gemini はクリーンだが、再解釈が入る傾向がある という違いでした。 最新検証：観点別比較 プロンプトの構造を定義したところで、次なるステップは「どの実行エンジン（AI モデル）が最も安定して仕様通りに動くか」のベンチマークテストです。私たちは、構図・人物・色彩・命令遵守性の 4 つの観点から、プロダクト運用への適性を評価しました。 ① 構図の安定性—— UI に馴染むか？ インフォグラフィックにおいて、余白と主体のサイズ感は「UI の整合性」に直結します。 ChatGPT は視点・余白・被写体のバランスが安定しており、複数枚を並べた際の一貫性が高い結果となりました。 一方 Gemini は、微妙な視点変更や背景処理の差異が発生しやすく、量産時の揺らぎがやや大きい傾向が見られました。 ② 人物表現の精度—— 意図が伝わるか？ 「シートベルトを締める」「スマホを見る」といった具体的な動作の正確さを検証しました。 人物の顔パーツ・視線・身体バランスにおいて、ChatGPT は安定したクオリティを維持しました。 Gemini は柔らかいトーンで描写される一方、表情や骨格の一貫性に若干のばらつきが見られました。 ③ 用色とブランド整合性 ChatGPT は指定した色調レンジを忠実に守る傾向が強く、ブランドトーンとの整合性が高い結果となりました。 Gemini は自然なグラデーション処理を行う反面、色相・彩度が微妙に変化するケースがあり、厳密なトーン統制には追加調整が必要でした。 ④ 命令遵守性（Instruction Following）—— 仕様書通りに動くか？ 最も大きな差はここでした。 ChatGPT はプロンプト構造（Part 1 / Part 2）をほぼそのまま出力に反映する傾向が強く、設計思想と出力結果の対応関係が明確でした。 Gemini は意図を解釈し、最適解を“再構成”する挙動が見られ、創造性は高いものの、決定論的制御はやや難しいという印象です。 ※ 正密に Gemini が過度な再解釈を試みるからこそ、私たちは Part 1（定数層）において、より厳密なビジュアルのガードレールを定義し、封鎖（Lockdown）する必要があるのです。 各ツールの本性：創作のパートナーか、信頼の実行エンジンか Midjourney：気分屋な天才アーティスト 2025 年 10 月時点の検証では、Midjourney は 圧倒的な 「 映え 」を誇りました。一枚絵としての完成度は素晴らしいのですが、標準化という観点では少し「個性が強すぎ」ました。 情報量が多すぎて UI の邪魔をしてしまう。 構図がダイナミックすぎて、並べた時に統一感が出にくい。 つまり、「 クリエイティブな爆発力はあるが、規律を守るのが苦手なタイプ 」です。 Gemini：再解釈を試みるクリエイティブ・ディレクター Gemini 3 Flash などの最新検証では、非常にクリーンな UI イラストを生成してくれますが、時折「自分の色」を出したがる傾向があります。 構図や余白が毎回少しずつズレる「自由奔放さ」。 プロンプトを忠実に守るというより、「 意図を汲み取ってリミックスしてしまう 」挙動が見られました。これは創作には良いですが、量産プロセスでは「予測可能性」を下げる要因になります。 ChatGPT (DALL-E)：仕様書通りに動くシニアエンジニア 対照的に ChatGPT は、 プロンプトの構造をそのまま出力に反映する能力 （ Instruction Following ）が極めて高いことが分かりました。 構図が安定し、用色も保守的でルール化しやすい。 まさに DesignOps における 「 信頼できる実行エンジン 」 です。 「イラストを作る（Make）」ツールではなく、「運用する（Ops）」ツール としての適性が最も高いと判断し、現在は ChatGPT を中心に検証を進めています。 ※ もちろん、表現の幅や偶発的なひらめきという点では、Midjourney や Gemini に軍配が上がる場面もあります。 実装結果：Unlimited App で何が変わったのか？ 確立した標準スタイルは、現在 Unlimited App 内の「車種別イラスト」や「レベル選択カード」などで試験的に運用されています。「 AI で 8 割のベースを生成し、人間が最後の 2 割を整える 」というフローにより、制作スピードと一貫性が（ついに！）両立し始めました。 しかし、この取り組みは Unlimited App という「実験場」だけで完結するものではありません。私たちが構築したプロンプトの 2 層構造は、いわばデザインの「共通プロトコル」です。将来的には、「スタイル定数（Part 1）」というコンフィグを各ブランドの DNA に合わせて差し替えるだけで、社内のあらゆるプロダクトやサービスへこの仕組みを横展開（スケール）させていくことを目見据えています。プロダクトを跨いで「一貫性のあるビジュアルを即座にデプロイできる」状態——これこそが、私たちが目指す真の DesignOps の姿です。 やってみて分かった課題 数ヶ月の検証で分かったのは、プロンプトには「 賞味期限（Prompt Rot） 」があるということです。ツールのアップデートにより、昨日まで動いていた魔法の言葉が、今日には効かなくなる。 そのため、プロンプトを一度作って終わりにするのではなく、 継続的にリファクタリングしていく前提の設計 が必要です。今後は、これらのメンテナンスを自動化する「AI Agent 的なアプローチ」も視野に入れています。 まとめ：AI × DesignOps は何を変えうるのか 今回の検証を通じて確信したのは、生成 AI は単なる「魔法」ではなく、 DesignOps を再設計するための強力なトリガー であるということです。 標準化とは、自由を奪うことではありません。むしろ、「 どこを固定し（Constants）、どこを柔軟にするか（Variables） 」を定義することで、変化の激しいプロダクト開発においてクリエイティブな安定走行を可能にする行為です。 DesignOps は、デザインを「属人的な手癖」から「再現可能なプロセス」へと拡張します。この取り組みが、皆さんのプロダクトにおけるクリエイティブ運用のヒントになれば幸いです。

こんにちは。サイオステクノロジーのひろです。 先日OSC福岡、OSC広島でセミナー登壇してきました。 今回は登壇内容についてまとめていきたいと思います。 生成AIの概要を理解できる 生成AI×ツールで新たな価値を生み出せることを理解できる この2点を目的として以下のことについてお話してきました。 生成AIにできることできないこと 生成AIにツールを使わせる技術について 生成AIにロボットを操作させるデモ セミナーに使用した資料を交えつつセミナー内容について解説していきます。 生成AIってなに？ 生成AIとはコンテンツを新たに生み出してくれるAIのことを指します。 ユーザがプロンプトを入力することで生成AIは文章や画像や動画、音楽、音声等を出力してくれます。 例としては、テキスト生成であれば Gemini 3.0 GPT-5 Claude Sonnet 4.5 等がありますね。 まず、テキスト生成に焦点をあてて、LLMが文章を生成する過程について説明しました。 テキスト生成を行うLLM(大規模言語モデル)は膨大なテキストデータから言語のパターンを学習したもので、文脈から次に来る確率が高い言葉を予測し、リストアップされた言葉の中からランダムに単語を選択することを繰り返して文章を生成します。 例えば「今日はいい日だ。」という文章を生成する過程を考えてみます。 以下の図のように、まず、「今日は」の次に来る可能性が高い言葉として、「いい」、「天気」、「寒い」がリストアップされ、その中から確率で選択されます。今回は「いい」が選択されていますね。この操作を繰り返します。 ここで一点重要なのは生成AIは最も確率が高い言葉を選択するわけではないという点です。 試しに同じプロンプトを何度か生成AIに投げていただけると異なるレスポンスが来ると思いますので、この仕組みを実感できると思います。 LLMは言葉を理解しているのではなく、パターンを知っており、そのパターンに倣って言葉を連ねているということになります。こちらについては、永田さんの記事「 AIは「1+1って、2になること多いなあ」と思っている！？ 」でLLM内部で起こっていることについて解説されてるので気になった方は是非ご覧ください。 次に、生成AIモデルでできることできないことを切り分けるために、まずLLMモデルと生成AIサービスの違いの説明を行いました。 LLMと生成AIサービス。一体どう違うのかというと、機能が異なります。 LLM 生成AIサービス 機能 文章の生成 LLMの機能＋履歴保持、web検索、ファイルアップロード,etc 例 GPT-5等 ChatGPT,Gemini等 生成AIサービスにはLLMの機能に加えて様々な機能が追加されています。 例えば表にあるように履歴保持機能。これがあるとこれまでの会話の文脈を生成AIが理解してくれるのでしっかり会話が成り立ちますね。 web検索機能。最近の生成AIサービスは検索機能を持っており、生成AIにリアルタイムの出来事を回答させることもできます。例えば今日の天気等をGeminiに聞いてみると検索結果から回答してくれます。 ChatGPTやGemini等の生成AIサービスは純粋なLLMとは異なる機能を持っているということです。 そして、生成AIモデル単体でできることとできないことを挙げると以下のようになります。 LLM単体でできないことについて解説していきます。 最新の情報に関する回答 LLMモデルはリアルタイムで学習し知識を更新する仕組みはなく、知識のカットオフ日が存在します。 カットオフ日とは、LLMが学習したデータがいつまでのデータかを指し、LLMはその日までのデータしか知り得ません。 そのため、例えば今日の天気を聞いても学習していないので回答することができません。 試しにGPT-4o-miniに対し、カットオフ日について尋ねてみました。 私の知識のカットオフ日は2023年10月です。それ以降の情報については持っていませんので、ご了承ください。何か質問があればお答えします！ このLLMは2023年10月までのことしか知らないというわけですね。 試しに「2025年は何が流行しそうか考えてみてください」と尋ねてみました。 2025年に流行しそうなトレンドについて、現在の技術や社会の動向を考慮した上でいくつかの予測を挙げてみます。 持続可能なライフスタイル: 環境意識の高まりに伴い、エコフレンドリーな製品やサービス、サステナブルなファッションが流行する可能性があります。プラスチックの削減やリサイクル製品の人気が高まるでしょう。 ウェアラブルテクノロジー: 健康管理やフィットネスのためのウェアラブルデバイスが進化し、より多機能で使いやすくなることで、一般的なアイテムとして普及するかもしれません。 メタバースとバーチャル体験: メタバース関連のプラットフォームが進化し、仮想空間でのソーシャルインタラクションやエンターテインメントが一般的になる可能性があります。特に、ゲームや仮想イベントが人気を集めるでしょう。 デジタルアートとNFT: デジタルアートやNFT（非代替性トークン）が引き続き注目され、アート市場やエンターテインメント業界で新しい形のクリエイションが流行するかもしれません。 パーソナライズされた医療と健康: 個別化医療や遺伝子ベースの健康管理が進展し、自分に最適な健康法や食事が提案されることで、健康志向のライフスタイルが流行する可能性があります。 リモートワークとフレキシブルな働き方: リモートワークやハイブリッドな働き方が一般化し、職場環境や働き方に関する新しいトレンドが形成されるでしょう。これにより、ワークライフバランスを重視する文化が広がる可能性があります。 エンターテインメントの新形態: ストリーミングサービスやポッドキャスト、バーチャルコンサートなど、デジタルコンテンツの消費スタイルが進化し、新しいエンターテインメントの形が流行するかもしれません。 これらはあくまで予測であり、実際に何が流行するかは様々な要因によって変わるでしょう。未来のトレンドは常に変化し続けるため、柔軟な視点で見ることが重要です。 もう2026年ですが2025年の流行を予想してもらいました。 あたっているかはさておき、このようにカットオフ日以降のことは知らないんですよね。 これから時間が経って、年齢を重ねたころにこのモデルと会話できたら懐かしい気分になれるかもしれません。 独自の情報に関する回答 LLMはもちろん学習したことしか知りません。 そのため、例えば会社の社内規約等のクローズドな情報について聞いても回答することができません。 情報の正確性の保証 LLMにはハルシネーションという、あたかも真実を語るように真っ赤な噓を吐くことがあります。 LLMが文章を生成する過程でもお話しましたが、LLMは、確率で単語を選び、それを繰り返して文章を作成するので、正しいこと以外も出力します。 LLMが本当に正しいことを言っているのか、人間が確認する必要があります。 複雑な計算 何か計算してとLLMに入力したとして、LLMは実際に計算しているわけではなく、学習パターンに基づいて次来る単語を生成しているため、複雑な計算は間違えることがあります。 AIは計算を理解しているわけではなく、 「1+1って、2になること多いなあ」と思っている ということですね。 現実世界やデジタル環境の操作 LLMはテキストを生成するのみで、例えば部屋の電気は消してくれませんし、notionでドキュメントを作成してくれることはありません。 このように生成AIにはできないことがありますが、これはツールと組み合わせることで解消できる場合があります。 生成AI×ツール 生成AIとツールを組み合わせることで多くのことができるようになります。 セミナーでは、RAG、FunctionCalling、MCPについてご紹介しました。 RAG RAGはRetrieval Augmented Generationと呼ばれ、検索拡張生成等と訳される技術です。 生成AI×検索ツールですね。 生成AIが検索ツールを使用してデータを検索し、取得したデータを基に回答を行います。 RAGを活用することで、生成AIはリアルタイムの情報や学習していない独自の情報を手に入れることができます。 また、情報源が明確になるため、根拠のある回答をしてくれますし、根拠をユーザが確認することができるようになります。 前章で挙げた生成AIにできないことのうち以下の項目については解消できそうと思っていただけるのではないでしょうか。 最新の情報に関する回答 独自の情報に関する回答 情報の正確性の保証 Function Calling 次にFunctionCallingです。 FunctionCallingは生成AIに関数を呼び出させる機能です。 関数の実行はアプリケーション側で行うため生成AIのレスポンスを翻訳する部分は実装する必要がありますが、生成AIがどの関数をどんな引数で実行するのか判断してくれます。 例えば検索、計算、外部APIの使用、IoT連携等、様々な機能を生成AIと組み合わせることが可能です。 複雑な計算ができる関数を用意しておけば、生成AIが苦手な計算だけ関数にさせることもできますし、ロボットを動作させる関数なんてのを作成しておけば、生成AIにロボットを操作させることもできるというわけですね。 組み合わせ次第で強力なものが生まれそうな気がします。 Azure OpenAIでFunctionCallingを行う方法については こちら のブログ記事で解説してますので興味がある方はぜひご覧ください。 MCP MCPはAnthropic社が提唱した、生成AIとツールを繋ぐUSB-typeCのような共通規格です。 これまでFunctionCallingを用いたLLMアプリを作成した場合、あるツールを別のアプリでも使用したいとなった場合、アプリ間の言語が異なったり必要なライブラリが異なれば、関数を改修する必要がありました。 また、ツールリストの定義方法はLLMによって異なるため、アプリで使用するLLMが異なれば、その点を改修する必要が出てきます。 MCPを使用した場合、MCPクライアントというものを用意し、LLMアプリと別プロセスで動作するMCPサーバをツールとして扱うようにします。 そうすると、MCPサーバ１つ作成すれば、どのLLMアプリからも使用できるようになるので、アプリ毎に関数を書いたり、ツール定義を行う必要がなくなります。 また、MCPサーバを公開しているサービスは増えており、例えばnotionやblender、googleカレンダー等のＭＣＰサーバを組み込むことが容易です。 公開されているMCPサーバについては こちら をご確認ください。 生成AIとツールを組み合わせる技術であるRAG、FunctionCalling、MCPについて解説を行いました。 続いてデモの解説に移ります。 Qumcum連携 具体的にFunctionCallingでQumcumを生成AIに操作させるデモを行いました。 QumcumはBluetoothによる通信が可能な小型ロボットです。 主な機能は距離センサや音検知、発声等がありますが、今回使用したのは頭、腕、足の回転です。 また、LLMとしてAzure OpenAIのモデルを使用しました。 Azure OpenAIについてはデプロイから実際にAPIを叩くまでをブログ記事にしていますので こちら をご確認ください。 シーケンス図は以下のようになります。 まず、プロンプトの分析をLLMにリクエストし、結果を構造化出力させています。これは分析結果(プロンプトから読み取れる感情、プロンプトに対するロボットの感情、プロンプトの要約等)をUIとして表示するために使用しています。 構造化レスポンスについてもブログにまとめているので、 こちらの記事を ご覧ください。 その後、分析結果とプロンプト本文をLLMに渡し、FunctionCallingを行います。 使用する関数を選択してもらい、アプリケーション側でロボット動作関数を実行しています。 デモ動画はこちらです。 このデモでは、入力したプロンプトからFunctionCallingによって関数が選び取られていることを表しています。 ロボットが万歳をする関数や、足踏み、首振りを行う関数が選び取られ、実行されているのがわかります。 今後の展望 具体的な展望ではないですが、今後できたらおもしろいなと考えていることは以下のようなことです。 テキスト入力から音声入力へ修正 Qumcumの発話機能を活用し、リアルタイム会話機能実装 今までの会話内容を記録し、RAGによって相棒、友人のような会話を可能に RAGを用いて生成AIの相棒を作るはらちゃんのブログは こちら を参照ください。 生成AIとツールを組み合わせることで、某未来から来たネコ型ロボットのような友人を自分の手で作ることができるかもしれませんね。 まとめ 生成AI×ツールによって、生成AI単体ではできなかったことが可能になります。 最新の情報に関する回答 独自の情報に関する回答 現実世界やデジタル環境の操作 等が可能です。 FunctionCallingやMCPを活用して新たな組み合わせによる新たな価値を生み出していきましょう。 閲覧いただきありがとうございました。 セミナーに参加してくださった皆さん、ご清聴ありがとうございました。 わかりやすく伝えられるセミナーを今後も行っていきたいと思います。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post OSC福岡＆広島2025で生成AI×ツールについてセミナー登壇してきました first appeared on SIOS Tech Lab .