この記事でわかること AivisSpeech（無料のローカル音声合成）＋ HyperFrames ＋ Claude Code の3つで、ナレーション・字幕・音声付きの解説動画が作れます。動画編集ソフトは使いません。 人間がやることは 「フォルダを1つ作る」「指示を2つ出す」「Claudeの質問に答える」 だけ。後は動画の完成まで待つだけで動画ができました。 ただし前提として Node.js と FFmpeg が必要です。入っているかは Claude が最初に点検してくれるので、足りなければその場で追加して貰えます。 音声モデルには ACML（Aivis Common Model License） が適用されます。 営利利用が禁止された ACML-NC 1.0 のモデルもある ので、使う前にどちらが適用されるかを 条文 で確認してください。 できたもの：3分26秒の解説動画 「生成AIの基礎」を、博士役と生徒役の会話で説明する動画です。中央のSVG図解が、そのとき話しているセリフに合わせて動きます。 https://www.youtube.com/watch?v=2lvo5-Ze4EU 中身の数字はこんな感じです。 項目 数字 尺 3分26秒（7トピック） 総フレーム数 5,400枚 MP4書き出し時間 1分55秒 着手から完成まで 約2時間 僕はイラストを描いていないし、音声も録っていないし、動画編集ソフトも開いていません。台本も書いていません。 :::message 本来は、できた動画の内容や台本を人の目で確認してから公開すべきです。ただ今回は「AIに任せるとこんな動画ができる」を知ってもらうため、 AIが作った動画をあえて無修正のまま 載せています。 実際、字幕で「生成AI」と書くべきところが「生成エーアイ」になっているミスが残っています。最後は人の目での確認が欠かせないことも、動画を見てもらえれば伝わるはずです。 ::: 役割分担：HyperFrames・AivisSpeech・Claude Code 登場人物が3つあるので、先に整理します。 ツール 役割 AivisSpeech 日本語の音声合成。テキストを渡すと喋ってくれる HyperFrames HTMLから動画（MP4）を書き出すフレームワーク。HeyGen製 Claude Code 上の2つを実際に組み立てる担当。台本もHTMLもコードも書く つまり「HyperFramesで動画を組む人」がClaude Code です。僕はClaudeに日本語で作りたい動画について指示して、Claudeからの質問に答えているだけです。 作業の全体像：7ステップ 細かい話の前に、全体の流れです。ここから先はこの順番で進みます。 # やること どこで 1 AivisSpeech をダウンロードして起動する アプリ 2 AivisHub から音声モデルを2つ以上追加する アプリ 3 フォルダを1つ作って Claude Code で開く ターミナル 4 指示を2つ送る Claude Code 5 Claude の質問に答える Claude Code 6 プレビューで確認する ブラウザ 7 MP4 に書き出す Claude Code 手を動かすのは1〜4までで、5から先はほとんど待っているだけです。 手順1：AivisSpeechをダウンロードして起動する 公式サイトからダウンロードしてインストールします。無料です。 https://aivis-project.com/ 起動するとこの画面になります。左に選択中の話者、右に話速や音高のスライダーがあります。 起動直後。この時点でテキストを打って再生ボタンを押せば、もう喋ってくれます ここで一度、適当なテキストを入れて再生してみてください。声が出れば準備OKです。 :::message このアプリは起動しているだけでいい 、というのが大事なポイントです。 AivisSpeechは裏側で音声合成のサーバー（ 127.0.0.1:10101 ）を立てていて、Claudeが書いたスクリプトはそこに話しかけて音声を作ります。人間がこのアプリを操作する場面は、実は一度もありません。 ::: 手順2：AivisHubから音声モデルを追加する デフォルトの声だけでもいいのですが、今回は「博士」と「生徒」の2人が会話するので、 声が2つ以上必要 です。声は AivisHub というサイトから追加します。 追加のしかたは2通りあります。アプリ内から探す方法と、ファイルをダウンロードして入れる方法です。メニューバーの「音声合成モデル」から両方に行けます。 「音声合成モデルのインストール・管理」と「AivisHubで音声合成モデルを探す」の2つが入口です AivisHubで探して選ぶ 「AivisHubで音声合成モデルを探す」を選ぶと、モデル一覧が開きます。ダウンロード数順に並んでいて、キャラクターの絵と「若い女性の声」「中年男性の声」といったタグ、それにスタイル数が見えます。 ダウンロード数の多い順。「6スタイル」「7スタイル」という表記が、その声で使える喋り方の種類です 気になったモデルをクリックすると詳細ページに行きます。今回博士役に使った「阿井田 茂」はこんなページです。 ボイスサンプルが聴けます。右側の「詳細情報」にライセンスとファイルサイズ（251.14MB）が書かれています ここで見るべきは3つです。 スタイル … ノーマル / Calm / Far / Heavy / Mid / Shout / Surprise のように、同じ声で複数の喋り方が使えます。今回は落ち着いて断定してほしかったので Calm を選びました。 ボイスサンプル … 実際の声を聴けます。声の印象は説明文だけではわからないので、聴いて頂くと、どれを使うかのイメージが湧きます。 ライセンス … ACML 1.0 と書かれています。ここは飛ばさないでください。 ACML-NC 1.0 のモデルは営利目的の利用が禁止 されているので、業務で使うなら必ず見る必要があります（詳しくは後述）。 AIVMXファイルをダウンロードして入れる 詳細ページの「AIVMX をダウンロード」を押すと .aivmx というファイルが落ちてきます。これを AivisSpeech に読み込ませる方法です。 Aivis Speechを開き、「音声合成モデル」→「音声合成モデルのインストール・管理」→ 右上の「インストール / 更新」を開きます。 「ファイルからインストール」でダウンロードした.aivmxを選ぶだけ。URL直指定もできます 入れ終わったら、管理画面で確認します。 5モデル入った状態。「まお」は6スタイルで、クレジット表記の指定まで書かれています 2つ以上入っていれば会話形式の動画が作れます。 手順3：フォルダを1つ作ってClaude Codeで開く ここからターミナルです。1行だけです。 mkdir hyperframes 動画制作用のフォルダを用意します。フォルダ名は何でもいいです。 空のフォルダで始めて、後はClaudeがこの中に必要なファイルを全部作ってくれます。 後は作ったフォルダをClaudeのアプリのClaude Codeで開くだけ。 手順4：指示は2つだけ 実際に打った文章をそのまま載せます。コピペして使えます。 Hyperframesで動画を作る為のプロジェクトのセットアップを行なって。公式のスキルもあるからそれもセットアップを行なって これを送るだけ。「公式のスキルも」と付けるのがポイントです HyperFramesには公式のスキル（Claudeへの取扱説明書のようなもの）が用意されていて、これを入れておくとClaudeがHyperFrames特有のルールを踏み外さなくなります。逆に、これがないとClaudeは手探りになります。 Aivis Speechを使って生徒役と博士役で会話しながら生成AIの基礎知識の説明動画を作成して。その際にSVGのアニメーションを最大限使って視覚的にもわかりやすい工夫もして。 この一文に入れた指定は4つだけです。 指定 書いた言葉 声をどうするか 「Aivis Speechを使って」 誰が喋るか 「生徒役と博士役で会話しながら」 何の動画か 「生成AIの基礎知識の説明動画」 見せ方 「SVGのアニメーションを最大限使って」 尺も、シーン数も、どの声を使うかも指定していません。 それはこの後Claudeが聞いてきます。 手順5：Claudeの3つの質問に答える 2つ目の指示を送ると、Claudeはいきなり作り始めません。まず環境を調べて、使える声を一覧にして、それから質問してきました。 質問1：尺とカバー範囲 動画の尺とカバーする範囲はどれくらいにしますか？（ここで台本量・シーン数・SVG図解の点数が全部決まります） 選択肢は「約90秒 / 3トピック」「約2分 / 4トピック」「約3分 / 6トピック（推奨）」「約5分 / 9トピック」。 推奨の3分を選びました。 質問2：声の配役 声の配役はどの組み合わせにしますか？（上のサンプルMP3を聴いてから選んでください） ここが良かったところで、 Claudeが先にサンプル音声を作って聴かせてくれました。 各モデルの説明文はAPIから取れなかったそうで、代わりに「各音声が自分の名前を名乗ってから博士／生徒のセリフを読む」音声を実際に合成してくれたんです。 聴いた上で「博士＝阿井田 茂 Calm / 生徒＝まお ふつー」を選びました。 質問3：画面の見せ方 画面の見せ方（SVGの使いどころ）はどれにしますか？ 「左右にSVGキャラ常駐＋中央に図解」「キャラなし・全画面図解＋話者バッジ」「キャラは小さくコーナー＋図解を大きく」「全身SVGキャラ＋ホワイトボード演出」の4択。選択肢にアスキーアートのレイアウト案が付いていたので、イメージしやすかったです。 「左右にキャラ＋中央に図解」を選びました。 台本のレビューは飛ばしてOK この後Claudeは台本（ SCRIPT.md ）を書いて、「ここで一度レビューを挟みます」と言ってきます。 :::message まず動画が作れるかどうかを試したいだけなら、 ここは読まずに「進めて」で大丈夫です。 台本を直したくなったら後からいくらでも直せます（詳しくは後述）。僕も1本目は流しました。 ::: 手順6：プレビューで確認する 台本ができて、音声が合成されて、HTMLが組み上がると、ブラウザで確認できます。ブラウザが立ち上がらなかったらClaudeにブラウザの立ち上げてプレビューしたい旨使えればOKです！ HyperFramesの編集画面（Studio）が開きます。 左が各シーンのファイル、中央がプレビュー、下がタイムライン。00:00 / 03:25 と尺が出ています この画面で見るところは3つです。 中央のプレビュー … 再生ボタンで実際に動きます。音も出ます。 下のタイムライン … Topic 1 〜 Topic 7 が時間順に並んでいます。どのシーンが何秒から何秒までかがひと目でわかります。 左の一覧 … 各シーンが compositions/topic-1.html のような別ファイルになっています。1つのシーンだけ直しても他に影響しません。 直したいところがあれば、Claudeに日本語で言えば直してくれます。「シーン3の図解が速すぎる」でも通じます。 手順7：MP4に書き出す プレビューでOKなら書き出します。動画を書き出してと伝えるだけでOKです！ 3分26秒の動画で 1分55秒 で終わりました。5,400フレームを1枚ずつ描いて繋げているので、尺が伸びるとその分時間がかかります。 これで out/seisei-ai-no-kiso.mp4 ができあがり。 完成度を上げるなら：台本チェックとキャラクターの用意 1本目は「作れるかどうか」の検証なので、流れに乗るだけでいいと思います。そのうえで、ちゃんとしたものを作るなら追加でやることが2つあります。 1. 台本（SCRIPT.md）をレビューする SCRIPT.md がこの動画の肝です。セリフはもちろん、尺・字幕・口パク・図解のタイミングまで、全部ここから逆算されて動画が出来上がります。 内容の正しさは人間しか判断できないので、社外に出す動画なら必ずここを読んでください 2. キャラクターを自分で用意する 今回のキャラクターは Claudeが描いたSVG です。動くし表情も変わりますが、見た目は簡素です。図解の方は十分見られるものになったので、伸びしろがあるのはキャラの絵の方でした。 作り込むなら、PSDなどで パーツごとにレイヤーを分けて 描くのがいいと思います。 ここのキャラクターの作り方はまた別の機会で試せたら紹介しますね！ 顔・体・目（開閉）・口（あ / い / う / え / お / 閉じ）を別レイヤーにする パーツごとに PNG か SVG で書き出す 書き出したファイルを1つのフォルダでまとめてClaudeに「このキャラに差し替えて」と伝える 口の形は「あいうえお＋閉じ」の6種類あれば足ります。AivisSpeechは音声を作るときに「どの母音を、いつ、どれだけの長さ発音するか」というデータを返してくれるので、そこから口の形が自動で切り替わります。だからパクパク動いているだけの口ではなく、実際の発音に合った口になります。 留意事項：社内ルールとライセンスの確認 ここは飛ばさずに読んでください。 各ツールの利用は所属会社のルールに沿って この記事で使ったツールはどれも外部サービスです。 業務で使う場合は、必ず所属する会社のルールや利用可否の基準に沿って利用してください。 何を入力していいのか、成果物をどこまで公開していいのかは会社ごとに違います。 AivisSpeechの音声モデルはライセンスを確認する 音声モデルには ACML（Aivis Common Model License） が適用されます。条文はGitHubで全文公開されているので、 使う前に必ずここを読んでください。 https://github.com/Aivis-Project/ACML/tree/master 一番大事なのは、 ACMLには2種類ある ということです。 ライセンス 営利利用 ACML 1.0 個人・法人・非営利・営利すべて可。 商用利用OK ACML-NC 1.0 営利目的の利用は禁止。 個人の私的な創作活動や、教育機関での教育・研究といった非営利利用のみ 同じAivisHubに並んでいても、 どちらが適用されるかはモデルごとに違います。 会社のブログやサービスで使うなら営利利用に当たる可能性があるので、 -NC が付いていないかを最初に確認してください。 ライセンス名は AivisHubの詳細ページの「詳細情報」欄 と、 AivisSpeechの管理画面 の両方に書かれています。今回博士役に使った「阿井田 茂」は ACML 1.0 でした。 禁止事項は両ライセンス共通で、次の7項目です。 話者や他者の本人・原作者・公式関係者であると誤解させる利用 話者のイメージ・尊厳・品位・社会的評価を傷つける利用 実在の人物・団体・商品などを批判・攻撃・嫌がらせ・誹謗中傷・差別する活動 虚偽の情報やコンテンツを流布する活動 虚偽・誇大表現によるマーケティング、倫理的に問題のあるビジネス 特定の政治的立場・宗教・陰謀論への賛同や反対を呼びかける活動 反社会的・犯罪目的での利用 クレジット表記は、ACML 1.0 と ACML-NC 1.0 のどちらでも「任意」 と明記されています。ただしモデル側から表記のしかたの希望が書かれている場合があるので都度確認をお願いします。 :::message alert 上のまとめは2026年9月時点の条文を読んだものです。条文は更新される可能性があるので、判断するときは必ず ACMLの原文 を確認してください。 ::: まとめ やったことを並べ直すと、こうなります。 AivisSpeechを入れて起動する AivisHubから声を2つ以上追加する フォルダを1つ作って、Claude Codeで開く 指示を2つ送る Claudeの質問に答える プレビューで見る 動画を書き出す 動画編集ソフトを開いていません。イラストも描いていません。台本も書いていません。 それでも音声・字幕・図解が揃った3分26秒の動画が出てきました。 一番の発見は、 「動画を作る」が日本語で発注できる作業になっていた ことでした。「生徒役と博士役で会話しながら」「SVGアニメーションを最大限使って」——このくらいの粒度で伝わります。細かいことは向こうが聞いてきます。 作りたい動画のイメージが頭にあるなら、フォルダを1つ作るところから試してみてください。1本目は台本レビューも飛ばして、まず出てくるかどうかを見るのがおすすめです。

この記事でわかること MCPサーバーはPythonやTypeScriptだけでなく、Spring AIを使えばJava(Spring Boot)でも構築できる MCPサーバー機能は、Spring AIの公式スターターを使えば簡単に既存のSpring Bootアプリに組み込める(サーバー設定はapplication.ymlのみ) 既存アプリがSpring SecurityのOAuth2 Resource Serverで認証していれば、MCPの認可に必要なメタデータ公開(RFC 9728)も含めてSpring Securityの標準機能で対応できる AIエージェントがCMDBの構成情報を自分で参照できるようになると、Atlassian MCPなど他のMCPとも組み合わさって、脆弱性対応やEOL対応といった業務がエージェントとの1つの会話で完結する はじめに こんにちは。KINTOテクノロジーズ(以下、KTC) プラットフォームグループ Platform Engineeringチームの山田です。普段は社内向けのCMDBを内製開発していて、ここ最近はCMDBと生成AIを組み合わせる取り組みを続けています。 CMDBそのものやSpring AIについては過去の記事で紹介しているので、あわせてご覧ください！(CMDBの記事は少し古いですが、雰囲気は伝わるかと思います) https://blog.kinto-technologies.com/posts/2023-12-14-CMDB/ https://blog.kinto-technologies.com/posts/2025-06-11-springAI/ 今回はその続きとして、CMDB本体(Spring Boot製)にMCPサーバー機能を追加し、AIエージェントから社内の構成情報を直接検索できるようにしました。 背景 Claude CodeなどのAIエージェントだけで業務を進める場面が、この1年で一気に増えてきていると思います。社内でも各種MCPサーバーやスキルなどの整備が進み、調査・実装・ドキュメント作成の多くをエージェントに任せられるようになっています。 一方で、困っていたのが、今回の主役であるCMDB (Configuration Management Database: 構成管理データベース) のデータです。CMDBは、プロダクト・チーム・GitHubリポジトリ・脆弱性・SBOMといった社内の構成情報を一元管理するデータベースで、KTCでは内製開発しています(詳しくは冒頭の過去記事をご覧ください)。せっかく構成情報を集約しているのに、これまでの参照手段はWebアプリだけでした。そのため、エージェントで作業をしていてCMDBのデータが必要になるたびに、以下の作業が発生していました。 CMDBのWebアプリを開いてキーワード検索する 検索結果のテキストをコピーして、エージェントのプロンプトに貼り付ける この間、エージェントの作業は止まり、人がWebアプリとエージェントの間でデータを受け渡すだけの作業に時間を取られます。せっかく構成情報を一元化したのに、AIエージェントからは参照できない状態でした。 この手作業での受け渡しをなくすため、CMDBをMCPサーバー化することにしました。 CMDBのMCPサーバーで何ができるようになったか 先に、できるようになったことの紹介です。 たとえば、あるライブラリに脆弱性が見つかったとします。SBOM・GitHubリポジトリ・プロダクト・チーム・ユーザーなどを管理するCMDBのMCPサーバーができたことで、こうした脆弱性対応をAIエージェントとの1つの会話の中で完結できるようになりました。具体的には、SBOM情報から脆弱性のあるバージョンのライブラリを使っているGitHubリポジトリを洗い出し、リポジトリに紐づくプロダクトと管理チーム・担当者を特定し、担当者向けのJiraチケットの起票、さらには脆弱性を解消するPRの作成まで進められます。 ①〜③と⑤がCMDBのMCPツール、④はAtlassian MCP、⑥はエージェント自身のコーディング機能です。 ポイントは、CMDBのMCPサーバー単体で完結するのではなく、他のMCPやエージェントの機能と組み合わさることで業務が一気通貫になることです。AIエージェントは、参照できるコンテキストが増えるほど、対応できる業務の幅が広がります。CMDBにはエージェントが持っていない社内の構成情報が集まっています。これまで人が都度補っていたこれらの情報をMCPで提供することで、エージェントに任せられる範囲そのものを広げることができました。 脆弱性対応の他にも、たとえばEOL(サポート期限)対応にも同じ要領で使えます。期限切れが近いコンポーネントとそれを使っているプロダクトをCMDBのMCPツールで洗い出し、担当チームの特定からJiraチケットの起票までを、そのまま1つの会話で進められます。 MCPサーバーの実装にSpring AIを選んだ理由 MCPサーバーの構築というと、PythonやTypeScriptのイメージが強いかと思います。公式SDKの充実度やFastMCPのようなフレームワークの存在もあり、実装記事もその2つに偏っている印象です。 ただ、今回MCPサーバー化したい対象は、Spring Bootで実装済みの既存アプリでした。別プロセスでPythonやTypeScriptのMCPサーバーを立ててAPIを中継させる構成も考えられますが、Spring AIを使って既存アプリにMCPサーバー機能を組み込めば、以下の資産をそのまま使い回せます。 REST APIのために実装してきたビジネスロジック(service層) Spring Securityを使った認証認可の仕組み ECSへのデプロイや監視などの運用の仕組み 唯一の不安は「Entra IDを使った既存の認証認可が、AIエージェント相手でも同じように使えるのか」でした。MCPの認可仕様はOAuth 2.1ベースで比較的新しく、検証するまでは正直手探りでしたが、結論から言うとSpring Securityの標準機能で対応できました(詳細は実装の節でお話しします)。 もしSpring Bootでアプリケーションを開発・運用しているチームであれば、MCPサーバーの構築にSpring AIを選ぶメリットは大きいと思います。 技術スタック Java 21 Spring Boot 4.0 Spring AI 2.0 (spring-ai-starter-mcp-server-webmvc) Spring Security (OAuth2 Resource Server) Microsoft Entra ID (認可サーバー) AWS (CloudFront + ALB + ECS など) システム構成 既存のCMDBバックエンド(Spring Boot)に、MCPエンドポイント /mcp を追加した構成です。MCPサーバーのために新しく追加したインフラはありません。なお、図はMCPサーバーに関係する部分に絞っており、フロントエンドの配信経路などは省略しています。 実装 ここからは実装内容を紹介します。なお、記事中のコードは一部、省略・編集しています。 依存関係の設定 build.gradleにSpring AIのBOMとMCPサーバー用スターターを追加します。追加する依存関係はこれだけです。 ext { set('springAiVersion', "2.0.0") } dependencies { implementation 'org.springframework.ai:spring-ai-starter-mcp-server-webmvc' } dependencyManagement { imports { mavenBom "org.springframework.ai:spring-ai-bom:${springAiVersion}" } } サーバー設定はapplication.ymlのみ MCPサーバーとしての設定はapplication.ymlに書くだけで、Javaの設定クラスは1つも作っていません。あわせて、JWT検証(OAuth2 Resource Server)の設定も抜粋します。 spring: security: oauth2: resourceserver: jwt: issuer-uri: https://login.microsoftonline.com/${TENANT_ID}/v2.0 ai: mcp: server: name: cmdb-mcp version: 0.0.1 instructions: >- CMDB は KINTO Technologies (略: KTC) 社内の構成管理データベースのこと。 プロダクト・チーム・リポジトリ・脆弱性などの社内構成情報を検索できる。 protocol: STATELESS type: SYNC stateless: mcp-endpoint: /mcp annotation-scanner: enabled: true 設定のポイントを2つ紹介します。 1つ目は instructions です。ここに書いた文章はMCPの初期化時に一度だけエージェントへ渡されます。「CMDBとは何か」のような前提知識をここに置いておくと、各ツールのdescriptionで同じ説明を繰り返さずに済み、ツール定義のトークンを節約できます。 2つ目は annotation-scanner です。これを有効にすると、後述する @McpTool の付いたメソッドが自動でツールとして登録されるため、ツール登録用のBean定義も不要になります。 @McpToolでツールの実装 ツールは @McpTool を付けたメソッドとして実装します。プロダクト検索ツールを例に、実装の全体像を紹介します。 @Component public class ProductMcpTools { private final ProductService productService; public ProductMcpTools(ProductService productService) { this.productService = productService; } @McpTool( name = "searchProducts", description = """ プロダクトを検索します。一覧・絞り込み・詳細取得はすべてこのツール\ (productId 指定で1件の詳細、未指定で一覧)。""", annotations = @McpTool.McpAnnotations( readOnlyHint = true, destructiveHint = false, idempotentHint = true, openWorldHint = false)) public ProductSearchMcpResult searchProducts( @McpToolParam(description = "プロダクトID。指定すると1件の詳細を返す。一覧結果の productId を渡す", required = false) Integer productId, @McpToolParam(description = "プロダクトの所属部署(グループID)で絞り込み", required = false) String groupId, @McpToolParam(description = "true で削除済みプロダクトを検索。削除済みはこの指定時のみ取得可(既定: false)", required = false) Boolean deleteFlag) { SearchProductServiceParameter parameter = new SearchProductServiceParameter(); parameter.setProductId(productId); parameter.setGroupId(groupId); parameter.setDeleteFlag(Boolean.TRUE.equals(deleteFlag)); // 既存のREST API用serviceをそのまま呼び出す SearchProductServiceResult result = productService.searchProduct(parameter); return productId != null ? ProductSearchMcpResult.ofDetail(result) : ProductSearchMcpResult.ofList(result); } } このクラスの役割はControllerと同じです。引数を組み立てて既存のserviceを呼び、結果をエージェント向けに整形するだけで、ビジネスロジックは置きません。検索ロジック本体は、REST APIのために実装済みの ProductService をそのまま呼んでいます。 これだけでMCPサーバーのツールが実装できてしまいます。 今回実装した検索ツール12個のほとんどは、既存のservice層を変更することなく再利用できました。REST APIのために実装してきたservice層を、MCPツールからそのまま再利用できるのが、既存アプリに組み込む構成のいちばんのメリットだと思います。 ツール 概要 searchProducts プロダクトの一覧・詳細検索 searchGroups 部署(グループ)の一覧取得 searchTeams チームとメンバーの検索 searchUsers ユーザーの検索 searchDomains ドメインの検索 searchGithubRepositories GitHubリポジトリの検索 searchVulnerabilitySummaries 脆弱性サマリの横断検索 searchVulnerabilityDetails 脆弱性詳細の検索 searchSbom SBOM(ソフトウェア部品表)の検索 searchEol EOL(サポート期限)の検索 searchArn AWSリソース(ARN)の検索 searchSchedules 開発環境のコスト削減を目的とした、AWSリソース起動停止スケジュールの検索 実装にあたって、3点補足します。 1つ目はツールヒント(annotations)です。MCPの仕様では、ヒントが未指定のツールは readOnlyHint=false ・ destructiveHint=true 、つまり「破壊的な操作をするかもしれないツール」というデフォルトで扱われます。エージェントが検索ツールの利用をためらわないよう、読み取り専用であることをヒントで明示しています。 2つ目は引数の形です。引数は1つのオブジェクトにまとめず、フラットに並べています。Spring AIはメソッドの引数をそれぞれinputSchemaのプロパティに変換するため、REST APIのようにパラメータクラスへまとめると、エージェントから見えるJSONスキーマに余計な階層ができてしまいます。既存のパラメータクラスの流儀とは意図的に変えている部分です。 3つ目はレスポンスの件数です。CMDBは、SBOMのように件数が膨大なデータも持っています(執筆時点で50万件超)。こうしたデータをそのまま返すと、エージェントのコンテキストを圧迫し、MCPの結果サイズ上限にも引っかかります。件数の多いデータを扱うツールでは絞り込み条件を必須にし、1ページ50件のページングと総件数(totalCount)の返却をあわせて実装しています。ページを分けても、データが足りなければエージェントがpageを変えて自分でツールを呼び直してくれるため、複数回の呼び出しで必要なデータを集められます。 認証認可 一番不安だった認証認可ですが、結論としては自前の認可サーバーを実装する必要はなく、既存のEntra IDをそのまま認可サーバーとして使えました。MCPの認可仕様の登場人物と流れは以下のとおりです。 sequenceDiagram participant Agent as AIエージェント<br/>(Claude Code等) participant MCP as CMDBバックエンド<br/>(MCPサーバー) participant Entra as Microsoft Entra ID Agent->>MCP: ① POST /mcp(トークンなし) MCP-->>Agent: ② 401 + WWW-Authenticate<br/>(メタデータの場所を案内) Agent->>MCP: ③ GET /.well-known/oauth-protected-resource MCP-->>Agent: ④ メタデータ応答<br/>(認可サーバー = Entra ID の場所) Agent->>Entra: ⑤ 認可コードフロー(PKCE)<br/>ブラウザでSSOログイン Entra-->>Agent: ⑥ アクセストークン(JWT) Agent->>MCP: ⑦ Bearerトークン付きでツール実行 MCP->>MCP: ⑧ JWT検証(署名・issuer・有効期限) MCP-->>Agent: ⑨ 検索結果 重要なのが③④のProtected Resource Metadata (RFC 9728)です。MCPサーバーは /.well-known/oauth-protected-resource でメタデータを公開し、「このサーバーの認可サーバーはどこか」をエージェントに教えます。エージェントはこれを読んで、自動的にEntra IDのログイン画面(ブラウザのSSO)へユーザーを誘導してくれます。 Spring側の実装は、ほぼ標準機能の組み合わせで済みました。 JWT検証: Spring SecurityのOAuth2 Resource Server。application.ymlの issuer-uri の設定だけで、Entra IDが発行したJWTの検証が動きます メタデータの公開: Spring Securityが標準でRFC 9728をサポートしており( OAuth2ProtectedResourceMetadataFilter )、認可サーバーの場所などをJavaの設定コード数行のカスタマイズだけで公開できます 1点だけインフラ側の対応が必要でした。RFC 9728のメタデータはドメインルートの /.well-known/ 配下で公開する必要がありますが、バックエンドは /api のコンテキストパスで動いています。そこで、CloudFrontで /.well-known/oauth-protected-resource* へのリクエストをALB(オリジンパス /api )にルーティングして解決しました。 ちなみに、Spring AIのドキュメントには、MCPサーバーの認証認可をコミュニティモジュールの mcp-security で実現する方法も紹介されています。 なお、AIエージェントによってOAuth周りの実装には微妙に差があり、あるエージェントでは問題なく接続できても、別のエージェントではエラーになることがありました。MCPサーバーを社内に展開する場合は、利用が想定されるエージェントで早めに接続確認をしておくと安心です。 AOPによる利用状況ログ 社内展開後の利用状況を把握するため、ツール呼び出しのログも仕込みました。 @McpTool アノテーションを対象にしたAOPのアスペクトを1つ書くだけで、ツールクラスが今後増えても自動でログ対象になります。ログにはツール名・ユーザーID(JWTのクレームから取得)・検索条件を構造化フィールドとして出力し、ダッシュボードで「誰がどのツールをどんな条件で使っているか」を集計できるようにしています。 実行結果 最後に、社内情報のためお見せできる部分が少なくなってしまいますが、実際の使用感をご紹介します。 接続 (Claude Codeの場合) 以下のコマンドでClaude CodeにCMDBのMCPを登録します。 claude mcp add --transport http cmdb-mcp https://xxxxx/api/mcp \ --client-id xxx \ --callback-port 29352 サーバー一覧でCMDBのMCPを選択し、認証を開始します。 ブラウザで認証をします。 ツールを呼び出してみる 試しにSpring Bootで構築しているプロダクト一覧を出してみます。 「Spring Bootで構築しているプロダクトを洗い出して」と聞いてみると、CMDBのMCPサーバーにあるSBOM検索ツールを spring-boot-autoconfigure のコンポーネントを検索条件に入れて呼び出します。 こちらがレスポンスの一部になります。全部で31プロダクトがSpring Bootを採用しているそうです。多いですね。 次のステップ 更新系ツールへの拡張: 現在は検索専用ですが、登録・更新系のツールも要望があります。誤操作のリスクが検索とは段違いなので、権限制御や実行前の確認の仕組みとセットで検討していきたいと思います さいごに 今回は、Spring Boot製の社内CMDBをSpring AIでMCPサーバー化し、AIエージェントから社内の構成情報を検索できるようにした取り組みについてお話ししました。 MCPサーバーの構築はPythonやTypeScriptの情報が多いですが、既存のSpring Bootアプリを持っているなら、service層も認証もインフラもそのまま使い回せるSpring AIは十分有力な選択肢です。この記事が、JavaでのMCPサーバー構築を検討している方の参考になれば嬉しいです。 AIエージェントを中心とした働き方はまだまだ進化していくと思うので、キャッチアップと実践を繰り返しながら、Platform Engineeringチームとしてツールの整備を進めていきたいと思います。

この記事でわかること Compose Multiplatform（CMP）の動画再生は、Android では AndroidView + Media3 PlayerView 、iOS では UIKitView + AVPlayerLayer 、Web では canvas の裏に置いた <video> 要素と、プラットフォームごとにまったく異なる Interop 機構で動いている 「どのフレームワークがネイティブか」は見せかけの問いで、デコードと撮像の層は Flutter も React Native も CMP もすべて OS の同じネイティブ API を使っている。本当の分岐点は「ネイティブが描いた 1 フレームを、フレームワーク自身の UI とどう合成するか」にある Android の SurfaceView / TextureView を画面ごとに選べる自由は CMP（と React Native）にはあり、Flutter の video_player には長らくなかった。一方、実際のプロジェクトでは角丸プレビューのために、あえて Flutter と同じテクスチャコピー経路（ TextureView ）を選んだ CameraK 0.4 やコミュニティ製の動画プレイヤーといった「若いエコシステム」の現実と、その不足を expect/actual で各プラットフォームのネイティブ API に直接下りて補うという対処法を、実プロジェクトのコードで示す はじめに こんにちは、モバイルアプリ開発部の Yao です。 私は以前から Kotlin Multiplatform（KMP）/ Compose Multiplatform を継続的に研究していて、このテーマで何本か記事を書いてきました。興味のある方は 過去の記事一覧 もご覧ください。本記事では、 CMP の弱点として真っ先に名前が挙がる「動画再生」と「カメラ」を、Android・iOS・Web の 3 プラットフォームでどう実装したか を書きます。 題材は、社内で開発した 動画アバター生成アプリ です。自分の顔を動画で録画してデジタル分身（アバター）を作り、テキストを入力するとその分身が自分の声で話す動画を生成する、というアプリです。録画・録音・再生というメディア機能がプロダクトの根幹にあり、「CMP でメディアをやるとどうなるか」を検証するには格好の題材でした。 生成された動画を確認・承認する VideoDetailScreen （本記事のアプリ画面はいずれもデザインモックで、人物はすべてダミーです） CMP のエコシステムはまだ若いです。この記事では、その若さがどこでどう痛むのか、そしてその痛みが expect/actual というアーキテクチャでどこまで緩和できるのかを、実際の行数・バージョン番号・コードで示します。形容詞ではなく数字で語ることを目標にします。 このアプリのアーキテクチャはどうなっているか 本アプリは 1 つの Kotlin コードベースから Android / iOS / Web（wasmJs）の 3 プラットフォームに配信しています。モジュール構成は次のとおりです。 androidApp ┐ iosApp ├─→ sharedUI ─→ sharedLogic ─→ apiClient webApp ┘ モジュール Kotlin ファイル数 役割 sharedLogic 113 Compose 依存ゼロ の純 Kotlin。Ktor / Serialization / Coroutines / Koin-core sharedUI 154 モバイル向け共有 CMP 画面 + 3 プラットフォームの actual 実装 webApp 35 モバイルのレイアウトは再利用せず、デスクトップ向けに再構築 apiClient 191 OpenAPI Generator 7.22.0 で生成しリポジトリにコミットした自社バックエンドのクライアント androidApp / iosApp 6 / 4（Swift） エントリポイントのみ 設計は Clean Architecture + MVI です。UseCase が 32 個（1 クラス 1 操作）、Repository が 7 個、ViewModel が 12 個あり、各 ViewModel は MutableStateFlow<XxxUiState> と不変 data class による単一の状態ソース（Single Source of Truth）を持ちます。プラットフォーム能力は 20 個の expect 宣言 に集約しています。 技術スタックはかなり新しめです。Kotlin 2.3.10 / CMP 1.10.1 / AGP 9.0.1 / Ktor 3.4.0 / Koin 4.1.1 / Navigation 3 1.0.0-alpha06 / Media3 1.9.0 / Coil3 3.3.0 / CameraK 0.4 / FileKit 0.13.0、そして wasmJs ターゲット。エコシステムの最前線に立つと何が起きるかは、後半で具体的に書きます。 プロジェクトの特徴を 1 つだけ挙げると、 ロジックは 100% 共有、UI は形態ごとに分岐 という方針です。Web はモバイルのレイアウトを再利用せず 33 個の独立した Web*Screen をデスクトップ向けに構築していますが、ViewModel の状態機械はモバイルとまったく同じものを使います。この「ロジックとプレゼンテーションの分離」が、後述するメディア実装の 3 プラットフォーム分岐を支える土台になっています。 なぜ Compose Multiplatform を選んだのか Flutter や React Native ではなく CMP を選んだ理由は 3 つあります。 1 つ目は、ロジックの複雑さが UI ではなく状態機械にあったこと。 本アプリのビジネスロジックには、本人確認（consent）のブラウザ連携の状態遷移、アバター生成状態の 3 値導出（ status × generationRetryable × retryCount → GENERATING / RETRYABLE / TERMINAL ）、動画生成とアバター訓練それぞれの 60 秒間隔ポーリングといった、型で守りたい遷移が多くあります。この種のロジックは、sealed interface と data class を持つ Kotlin で書くのが Dart や TypeScript より安全だと判断しました。 2 つ目は、チームのスキルセット。 メンバーは Kotlin / Android 出身で、UseCase 32 個 + StateFlow の MVI という構成は学習コストゼロで書き始められました。 3 つ目が最も重要で、「漸進的にネイティブへ戻れる」こと。 sharedLogic は Compose 依存ゼロの純 Kotlin なので、 Swift から直接呼べます 。実際 iOS はすでに SwiftUI のネイティブシェル + CMP コンテンツ画面というハイブリッド構成です。将来 UI をすべて SwiftUI / Jetpack Compose に置き換えることになっても、ロジック側は 1 行も変わりません。Flutter や React Native では、UI フレームワークを捨てる = ほぼ全部書き直しですが、KMP ではロジック資産がそのまま残ります。この退路の存在が、以前の記事 「Kotlin Multiplatform ハイブリッドモード」 で書いたハイブリッドモードの実利です。 「動画再生」と「カメラ」——若いエコシステムで最初にぶつかる壁 CMP でアプリを作ると宣言したとき、最初に聞かれるのが「動画とカメラはどうするの？」です。もっともな質問です。Flutter には flutter.dev 公式チームが保守する video_player と camera があり、React Native には無数のプロダクションで数年動いている react-native-video と vision-camera があります。CMP にはそれに相当する「公式の定番」がまだありません。 エコシステムの現実を数字で見る 本アプリの動画再生は io.github.kdroidfilter.composemediaplayer （ComposeMediaPlayer）というコミュニティ製ライブラリをベースにしています。Flutter の video_player のような公式チーム保守のプラグインではないので、挙動の細部を確かめたいときはライブラリの公開ソースを読み解くことになります。この記事の Interop 解説も、そのソースリーディングの成果です。 カメラは CameraK を使いました。バージョンは 0.4 です。Flutter の camera が公式チームの保守下にあり、 vision-camera が成熟していることと比べると、この数字がエコシステムの若さを端的に表しています。 それでもこの構成で 3 プラットフォームのアプリは出荷できました。なぜ成立したのかを説明するために、まず前提となる誤解を 1 つ解きます。 そもそも「ネイティブかどうか」は論点ではない クロスプラットフォームの比較記事では「Flutter は独自レンダリングだから」「RN はネイティブだから」という議論をよく見ますが、動画とカメラに関しては、 デコードと撮像の層は 3 者とも完全に同じ です。自前で H.264 デコーダやカメラドライバを書いているフレームワークは 1 つもありません。 フレームワーク / ライブラリ 再生のデコード カメラの撮像 Flutter： video_player / camera （いずれも flutter.dev 公式プラグイン） ExoPlayer / AVPlayer CameraX・Camera2 / AVCaptureSession React Native： react-native-video / vision-camera ExoPlayer / AVPlayer CameraX / AVCaptureSession 本アプリ（CMP） Media3 ExoPlayer / AVPlayer / <video> CameraK 経由の CameraX / AVCaptureSession、Web は getUserMedia を直接 どのフレームワークを選んでも、動画をデコードするのは ExoPlayer と AVPlayer で、カメラを制御するのは CameraX と AVCaptureSession です。つまり「画質」「デコード性能」「対応コーデック」でフレームワーク間に差は出ません。 では何が違うのか。 ネイティブ API がデコードした 1 フレームを、フレームワーク自身が描いた UI（ボタン、テキスト、角丸カード）とどう合成するか 。ここがすべての分岐点です。 本当の分岐点：ネイティブのフレームをどう合成するか 合成戦略は大きく 2 路線に分かれます。 路線 A：テクスチャ搬送。 ネイティブプレイヤーの出力を GPU テクスチャとしてフレームワーク側にコピーし、フレームワークが自分のシーングラフの中で 1 枚の画像として描く。Flutter の video_player は従来この方式が既定でした。 路線 B：ネイティブ view の埋め込み。 ネイティブの view（ SurfaceView / UIView / DOM 要素）をそのまま画面に重ね、フレームワークの描画面と OS のコンポジタで合成する。React Native と、CMP の Interop（ AndroidView / UIKitView ）はこちらです。 路線 A は毎フレームのコピーと引き換えに自由な変換を、路線 B はゼロコピー直結と引き換えに手動のレイヤー管理を受け入れる 両者の得失は明確に非対称です。 観点 路線 A：テクスチャ搬送（Flutter） 路線 B：ネイティブ view 埋め込み（RN / CMP） 角丸・クリップ・回転・拡縮 ✅ 動画はただの画像なので自由に変換できる ⚠️ ネイティブ層は親の clip を受けない（ SurfaceView の場合。 TextureView なら可） 他 UI との z 順の重なり ✅ 常に正しい ⚠️ 手動管理。Web ではほぼ不可能 リスト内スクロール ✅ フレーム同期が自然に取れる ⚠️ ネイティブ層がずれて「浮く」ことがある GPU 負荷 / 遅延 ⚠️ コピーと同期で約 1 フレーム分のコスト ✅ ゼロコピーでハードウェア合成に直結（ SurfaceView の場合） PiP（iOS）/ AirPlay / ロック画面操作 / ネイティブ字幕 ⚠️ 失われる。追加プラグインが必要 ✅ ネイティブプレイヤーの機能がそのまま使える DRM のセキュアパス（Widevine L1） ❌ テクスチャ経路では取得できない ✅ 可能（ SurfaceView が必要） この表を頭に入れたうえで、CMP が 3 プラットフォームでそれぞれどう実装しているかを見ていきます。本アプリでは ComposeMediaPlayer の上に 272 行のラッパー VideoPlayer.kt を被せ、成果物動画の再生（ VideoDetailScreen ）、アバターのプレビュー再生（ AvatarDetailScreen ）、録画素材の見直し（ AvatarCreateVideoReviewScreen ）とその Web 版、計 6 画面で使っています。 3 つのプラットフォーム、3 つの Interop Android：AndroidView と、SurfaceView / TextureView の選択権 Android 実装は AndroidView で Media3 の PlayerView を Compose ツリーに埋め込みます。興味深いのは、このライブラリが 動画を描く面（surface）を 2 種類用意していて、XML レイアウトで切り替えられる ことです。 <androidx.media3.ui.PlayerView android:layout_width="match_parent" android:layout_height="match_parent" app:surface_type="surface_view" app:use_controller="false" /> <androidx.media3.ui.PlayerView android:layout_width="match_parent" android:layout_height="match_parent" app:surface_type="texture_view" app:use_controller="false" /> SurfaceView は OS のハードウェアコンポジタに直結した独立レイヤーで、ゼロコピーかつ低遅延、DRM のセキュアパスもここを通ります。ただし 独立レイヤーであるがゆえに、親 View のクリップに参加しません 。一方 TextureView は動画フレームを GPU テクスチャとして View ヒエラルキーの描画に合流させるため、1 コピー分のコストと引き換えに、普通の View と同じように角丸クリップや変換が効きます。 本アプリのデフォルトは TextureView です。 @Composable actual fun VideoPlayerSurface( playerState: VideoPlayerState, modifier: Modifier, contentScale: ContentScale, overlay: @Composable () -> Unit ) { VideoPlayerSurfaceInternal( playerState = playerState, modifier = modifier, contentScale = contentScale, overlay = overlay, surfaceType = SurfaceType.TextureView ) } 理由は具体的です。アバター詳細画面（ AvatarDetailScreen ）のプレビューは 350×600 の角丸カードで、 SurfaceView を使うと角丸の内側から四角い動画がはみ出して、カードの角を突き破ります。デザインを守るには TextureView しかありませんでした。 問題の角丸プレビューカード。この 4 つの角を守るために TextureView を選んだ :::message ここに直感に反する事実があります。前節の表のとおり、 TextureView の「GPU テクスチャとしてコピーする」経路は、 まさに Flutter の video_player が従来常に通ってきた路線 A そのもの です。つまり本アプリは Android では、角丸というデザイン要件のために、Flutter と同じ性能特性を自ら受け入れています。 ::: ただし Flutter との違いは「選べること」にあります。 video_player も現在は VideoViewType.platformView で platform view を選べますが、この選択肢が入ったのは登場から長い年月が経ってからでした。CMP の路線 B では、 surfaceType 引数 1 つで 画面ごとに SurfaceView （性能・DRM 優先）と TextureView （クリップ・変換優先）を選び分けられます。角丸カードには TextureView 、全画面再生には SurfaceView 、という使い分けが同じアプリの中でできます。この選択権こそが路線 B の実利で、本アプリの角丸プレビューはそれを行使した実例です。 iOS：UIKitView と layerClass = AVPlayerLayer iOS 実装は 3 プラットフォームの中で最も素直です。CMP の UIKitView でネイティブ UIView を埋め込みますが、その UIView の backing layer 自体を AVPlayerLayer に差し替える という UIKit の古典的なテクニックを使っています。 private class PlayerUIView : UIView { companion object : UIViewMeta() { override fun layerClass(): ObjCClass = AVPlayerLayer } @OverrideInit constructor(frame: CValue<CGRect>) : super(frame) var player: AVPlayer? get() = (layer as? AVPlayerLayer)?.player set(value) { (layer as? AVPlayerLayer)?.player = value } } Objective-C の +layerClass オーバーライドを Kotlin/Native の UIViewMeta でそのまま書けている点に注目してください。view の layer が最初から AVPlayerLayer なので、余計なサブレイヤー管理が不要で、AVPlayer のデコード結果は Core Animation のコンポジタにゼロコピーで渡ります。あとは UIKitView(factory = { PlayerUIView(frame = cValue<CGRect>()) }, ...) で Compose に埋め込むだけです。 きれいな構図ですが、路線 B の代償はここにもあります。CMP の UIKitView はネイティブ view を Compose のシーングラフの中に描くのではなく、 Compose が描画している MTKView の兄弟としてその上に重ねます 。つまり動画 view は Compose の描画世界の外にいて、タッチイベントの透過、レイヤーの前後関係、クリップはすべて Interop の境界で個別に面倒を見ることになります。ComposeMediaPlayer がこの境界を吸収するために、再生コントロールなどを載せるための overlay スロットを API として用意しているのは、その裏返しです。 Web：canvas の裏の video 要素と、BlendMode.Clear で開ける穴 Web（wasmJs）実装は、この記事でいちばん劇的な部分です。CMP の Web ターゲットは画面全体を 1 枚の canvas（Skia）に描画します。では <video> 要素はどこに置くのか。答えは「 canvas の裏 」です。 internal fun HTMLVideoElement.applyInteropBehindCanvas() { val wrapper = parentElement as? HTMLElement ?: return wrapper.style.apply { zIndex = "-1" // <video> を Compose の canvas の背後へ setProperty("pointer-events", "none") backgroundColor = "transparent" } } z-index: -1 で動画をページの最背面に沈めます。当然このままでは canvas に隠れて見えません。そこでアプリ側のコードで、Compose の canvas に 文字どおり穴を開けます 。 // BlendMode.Clear zeroes every pixel (including alpha) in the Compose canvas // over this area, punching a transparent hole so the video element behind // the canvas shows through. Box(modifier = Modifier.fillMaxSize().drawBehind { drawRect(color = Color.Transparent, size = size, blendMode = BlendMode.Clear) }) BlendMode.Clear はその領域のピクセルをアルファ値ごとゼロにするので、canvas のその部分が完全に透明になり、背後の <video> が透けて見える、という仕掛けです。カメラのライブプレビューも同じ機構で、 getUserMedia() で取得した MediaStream を WebElementView 経由で HTMLVideoElement に接続し、canvas の穴から覗かせています。 動画は常に最背面。見えるのは canvas に開けた穴の領域だけで、UI は必ず動画より上に載る :::message これは 2 つ目の、直感に反する事実につながります。この方式の帰結として、 Web では動画は構造的に、すべての Compose コンテンツより下にしか存在できません 。「動画の上に UI を重ねる」ことは（canvas 側に描く限り）可能ですが、「UI の下に動画、そのさらに下に別の UI」のような自由な z 順は原理的に組めません。録画中のタイマー表示や停止ボタンは、この制約を前提に「穴の上に Compose で描く」設計になっています。これはバグや実装の手抜きではなく、canvas レンダリング + DOM 動画という構成の構造的な限界です。 ::: 公平を期すために書いておくと、 Web の動画は 3 フレームワークとも体面を保てていません 。Flutter Web の video_player も HtmlElementView で DOM の <video> を重ねる同類の方式で、canvas と DOM の合成に相応の制約とコストを抱えます。React Native には公式の動画プレイヤーがそもそもなく、 react-native-video の Web 対応もまだ発展途上です。ブラウザでは動画デコードとページ合成の主導権がブラウザ自身にあるため、どのフレームワークも <video> 要素と「同居」する方法を探すしかないのです。 カメラと録音：expect/actual が第一級市民である強み 動画再生はコミュニティ製ライブラリで戦いましたが、カメラと録音はもっと直接的に、 expect/actual で各プラットフォームのネイティブ API に下りて実装しました。まず実装量の実態を見てください。 能力 Android iOS Web 動画録画画面 AvatarCreateVideoRecordingScreen.mobile.kt 467 行 （Android / iOS 共有） 同左 AvatarCreateVideoRecordingScreen.wasmJs.kt 425 行 カメラ実装 CameraK 0.4（CameraX ベース） CameraK 0.4（AVCaptureSession ベース） getUserMedia() + MediaRecorder + WebElementView AudioRecorder 83 行（ MediaRecorder ） 108 行（ AVAudioRecorder ） 11 行の stub MicrophoneDeviceProvider 70 行 17 行 12 行の stub AudioPlayer 53 行 63 行 57 行（ HTMLAudioElement ） モバイル側の録画は CameraK に任せました。フロントカメラ固定・HD 画質・録画プラグインという構成が、Android / iOS 共通の 1 ファイルで書けます。 val cameraConfig = remember { CameraConfiguration( flashMode = FlashMode.OFF, cameraLens = CameraLens.FRONT, ) } val cameraState = rememberCameraKState( config = cameraConfig, setupPlugins = { holder -> holder.attachPlugin(plugin) }, // VideoRecorderPlugin ) CameraKScreen( modifier = Modifier.fillMaxSize(), cameraState = cameraState.value, content = { _ -> RecordingOverlay(/* 録画 UI */) }, ) 録画中の画面。カメラプレビュー（ネイティブ層）の上に、タイマー・スクリプト・停止ボタンを Compose の overlay として重ねている Web はライブラリなしで、 getUserMedia() と MediaRecorder を wasmJs から直接呼びます。mimeType のネゴシエーション（ブラウザごとに対応コーデックが違う）もブラウザ API の流儀のまま書きました。 表の中の「11 行の stub」は隠さず書いておきます。Web 版の AudioRecorder と MicrophoneDeviceProvider は中身のない空実装で、音声クローン用の録音フローはモバイル専用と割り切りました。3 プラットフォーム対応とは「全機能 × 全プラットフォーム」ではなく、プラットフォームごとに提供範囲を選ぶことでもあります。 expect/actual はこの割り切りも型として明示できます。 同じ状態機械、違うトリガー：ConsentReturnFromBrowserEffect expect/actual の使いどころとして、私が最も気に入っている例を挙げます。アバター訓練には本人確認（consent）があり、外部ブラウザで確認を完了してからアプリに戻ると、アプリ側が「戻ってきた」ことを検知してステータスの確認を始めます。この「外部ブラウザから戻ってきた」というイベントは、プラットフォームによって観測手段がまったく違います。 @Composable expect fun ConsentReturnFromBrowserEffect(onReturned: () -> Unit) Android / iOS （mobileMain・36 行）：Compose の lifecycle を観測し、 ON_PAUSE → ON_RESUME の順で来たときだけ発火。ブラウザを開けば必ずアプリが pause するので、初回 composition や無関係な resume を誤検知しません Web （wasmJs・36 行）： window の blur → focus を監視。wasmJs では lifecycle の ON_RESUME が確実には発火しないため、専用の経路を用意しました consent の状態機械そのもの（待機 → 確認中 → 完了）は ViewModel にあり、3 プラットフォームで完全に同一です。 違うのはトリガーの観測方法だけで、そこだけが actual として差し替わる 。状態機械のテスト・修正・拡張は 1 か所で済みます。 :::message ここが 3 つ目の、そしてこの記事で最も伝えたい、直感に反する洞察です。「CMP はエコシステムが若く、公式プラグインがない」という弱点は事実ですが、そのダメージは KMP のアーキテクチャによって 構造的にかなりの部分まで相殺されています 。Flutter で MethodChannel や PlatformView を書くのは「プラグインがないときの例外的な脱出路」という位置づけですが、KMP の actual は日常の文法そのものです。同じ AudioRecorder クラスを Android 83 行 / iOS 108 行 / Web 11 行で書き分ける作業は、型安全で、IDE 補完が効き、ビジネスコードと同じモジュールの中で完結します。「ライブラリがなければネイティブ API を直接呼べばいい」が、儀式なしで成立するのです。 ::: Flutter / React Native と比べたときの CMP の強みは何か 先に明確にしておきます。 「CMP の動画プレイヤーやカメラは Flutter より優れている」という主張は成立しません。 成熟度では公式保守の video_player / camera や実績豊富な vision-camera に及びません。そのうえで、このプロジェクトを通して実感した CMP 固有の強みは次の 3 点です。 1. Interop 路線の選択権がある。 CMP は路線 B（ネイティブ view 埋め込み）ですが、Android では SurfaceView / TextureView を画面単位で選べます。角丸が要る画面は TextureView 、性能や DRM が要る画面は SurfaceView 。Flutter の video_player には、このスイッチに相当する選択肢が長らく存在しませんでした。 AvatarDetailScreen の角丸プレビューカードは、この選択権の行使例です。 2. 「ネイティブに下りる」ことが第一級市民である。 前節のとおり、 expect/actual は例外処理ではなく日常の文法です。エコシステムに欠けている部品は、待つのではなく 83 行書けば埋まります。 3. ネイティブ API サーフェス全体に直接触れられる。 本アプリが使っているのは、Media3 PlayerView の app:surface_type 、UIView の layerClass 差し替え、 MediaRecorder の mimeType ネゴシエーションといった、各プラットフォームの 素の API です。プラグイン作者が切り出した「最大公約数的な抽象」を経由しないので、プラグインが公開していない機能のために上流（upstream）のリリースを待ったり PR を出したりする必要がありません。 引き換えに何を受け入れたか 強みだけ書いて終わる記事は信用できないので、CMP を選んだ引き換えに受け入れたデメリットも正直に書きます。 動画再生をコミュニティ製ライブラリ 1 本に依存している。 公式チーム保守という後ろ盾がなく、挙動の細部を確かめたり問題を切り分けたりするたびに、ライブラリ内部の Interop 実装まで読み解く理解コストがかかる カメラライブラリのバージョンは 0.4。 公式チームが保守する Flutter camera や、長年プロダクションで検証されてきた vision-camera と比べ、実績の厚みが違う Web の録音まわりは stub。 AudioRecorder 11 行、 MicrophoneDeviceProvider 12 行の空実装で、録音フローはモバイル専用に割り切った Web の動画は構造的に最背面。 BlendMode.Clear の穴あけ方式である限り、動画と Compose UI の z 順は「動画が常に下」で固定される これらを踏まえた私の判断はこうです。 プロダクトの重心がメディア能力そのものにあるなら、 vision-camera を持つ React Native がおそらく最も成熟した実用的な選択肢でしょう。 一方、重心が複雑なビジネス状態機械にあり、長期的にネイティブ UI へ回帰する可能性を残したいなら、CMP は正しい選択です。メディア層で余分に書いたコードは、「 sharedLogic を Swift から直接呼べる」「いつでもネイティブ UI に戻れる」という自由への入場料だったと総括しています。 まとめ 動画・カメラのデコードと撮像の層は、Flutter / React Native / CMP のどれを選んでも同じネイティブ API に行き着く。差が出るのは「ネイティブのフレームと自前 UI の合成方法」で、テクスチャ搬送（路線 A）とネイティブ view 埋め込み（路線 B）は得失が非対称 CMP は路線 B に立ちつつ、Android では SurfaceView / TextureView を画面ごとに選べる。本アプリは角丸プレビューのために、あえて Flutter と同じテクスチャ経路（ TextureView ）をデフォルトにした iOS は UIKitView + layerClass = AVPlayerLayer でゼロコピー再生。Web は canvas 背面の <video> に BlendMode.Clear で穴を開けて見せる方式で、動画が常に UI の下という構造的制約を受け入れた エコシステムの若さ（コミュニティ製の動画プレイヤー、CameraK 0.4、Web 録音の stub）は実在するコストである。同時に、 expect/actual によって「ネイティブ API に直接下りる」ことが日常の文法になっているため、そのダメージはアーキテクチャで大きく緩和できる CMP のメディアエコシステムは、あと数年は「自分の手を動かして埋める」フェーズが続くと思います。それでも、埋めるための道具立て—— AndroidView / UIKitView / WebElementView 、そして expect/actual ——は既に揃っていて、実プロダクトを 3 プラットフォームに出荷できる水準にあります。この記事の数字とコードが、同じ判断を迫られている方の材料になれば幸いです。 最後まで読んでいただき、ありがとうございました！

こんにちは。KINTOテクノロジーズ（KTC）で、ユーザーファースト推進活動の運営に関わっているる かーびー です。 KTCでは 「ユーザーファースト」 を会社の重点方針のひとつに掲げており、社内勉強会「ユーザーに寄りそわNight!」の開催もその取り組みのひとつです。 Vol.02 のレポートに続き、今回はVol.03の内容をお伝えします。 テーマは「クイックなリサーチ」。サービスに感じた「このまま進めていいのかな」という違和感を、すぐに改善案にせず、手元にある情報から一度確かめてみる進め方です。 サービスの企画や改善に関わっていると、「この動線で、必要な情報までたどり着けるのだろうか」「説明の途中で迷う人がいるのではないか」と感じる場面があります。 こうした違和感は改善を考えるきっかけになりますが、その時点では本当に問題が起きているのか、ユーザーにどんな影響があるのかまではわかりません。 生煮えのままチームに改善案をあげたとして、関係者の立場によって持っている情報や前提が異なるため、提案に至った背景から理解を取り付ける必要があります。一定の共感は得られるとしても、関係者が多いほど時間がかかるものです。 Vol.03で取り上げたのは、この違和感と改善案のあいだに、「確かめる」を一段はさむ実践でした。 第3回の寄りそわNightでは、デジタル戦略部の上田貴弘さんに登壇していただきました。オンライン相談やVoC（Voice of Customer：お客様の声）の分析、ユーザビリティテストなどを通じて、ユーザーの声や行動を捉える業務に取り組んでいます。当日は、オンライン相談やVoCから見えてきた仮説を、新入社員とのユーザビリティテストで確かめた事例が紹介されました。 新入社員に実際のサービスを使ってもらう 今回の事例の出発点は、オンライン相談やVoCを見る中で生まれた「サービスの利用途中に、いくつかのつまずきが起きているのではないか」という仮説でした。 ただ、相談や問い合わせからわかるのは、ユーザーが言葉にした困りごとが中心です。実際の画面上のどこで手が止まり、何が理解しにくかったのかまではつかめません。 そこで登壇者の上田さんが紹介したのが、新入社員に協力してもらうユーザビリティテストでした。 入社したばかりのメンバーは、業務やサービスに関する前提知識がまだ少なく、社内では当たり前になっている言葉や流れにも、初めてサービスに触れる人に近い反応を示します。社内メンバーなので確認したい内容を共有しやすく、短い準備で実施できる。実践のしやすさも、この方法が選ばれた理由の一つでした。 もちろん、新入社員がそのまま実際のお客様を代表するわけではありません。 今回は、サービスのどこにつまずきがありそうかをまず確かめるための検証です。 テストでは、実際に画面を操作してもらいながら、利用中の発話や迷い、説明を読んだあとの反応を観察していきます。説明を何度も読み返す、次に進まずに考え込む、前の画面に戻って情報を探す。 操作の様子を追うことで、どの場面で立ち止まったのか、どの説明が伝わりにくかったのか、判断するために何の情報が足りなかったのかが具体的になっていきます。 設計上は、説明を読めばそのまま次の画面へ進める想定でも、実際には同じ箇所を何度も読み返している。反対に、作る側が課題だと考えていた箇所では、ほとんど迷いが起きていない。登壇を通して繰り返し語られていたのは、この「想定」と「実際に起きていること」を分けて見ることの大切さでした。 紹介された例のひとつが、本人確認書類の画像アップロードです。最新のスマートフォンで撮ったきれいな写真が容量の上限を超え、エラーになる。設計した時点では問題のなかった仕様でも、ユーザーの利用環境が変わることで、思わぬところにつまずきが生まれます。実際の利用を見て初めてわかるつまずきは、こうした単純なところにも潜んでいます。 エラーに遭遇した人は、そのあと撮り直して先へ進めているのか。それとも、そこで利用をやめてしまっているのか。実際の行動が見えると、次に確かめたいことが具体的になります。こうして、ひとりの違和感が、チームで確かめられる問いに変わっていきます。 オンライン相談やVoCから感じていた違和感に実際の行動が重なったことで、「使いにくそう」という感覚だけでは見えていなかった部分が確認できた。そんな事例でした。 提案の前に、同じ景色を見る 確かめた結果を、チームでどう使うのか。この話題で登壇のキーワードになっていたのが「同じ景色を見る」という言葉です。 ここでいう「同じ景色」とは、全員が同じ意見になることではありません。改善案を挟んで向かい合うのではなく、ユーザーの行動や声を真ん中に置いて、隣に並んで見る。ユーザーに何が起きていたのか。どの情報から、課題かもしれないと考えたのか。何が変われば、困りごとが解消されたと言えそうなのか。立場や役割が違っていても、まずユーザーを共通の起点にして考える、という意味です。 改善案だけが先に出てくると、受け取る側は、何を解決しようとしているのか、なぜ今扱う必要があるのかを、まず確認しなければなりません。ユーザーの行動や発言、問い合わせ、ログが先に共有されていれば、改善案への賛否を決める前に、「何が起きていそうか」から話し始められます。 直したい箇所のリストは、開発の現場ではいつも長くなりがちです。 「一部の環境で画像のアップロードがエラーになることがある」という一行の報告と、目の前でユーザーが何度も写真を撮り直し、手を止めてしまう様子とでは、同じ事実でも受け取る重みが違います。 実際の行動を関係者が一緒に見ることで、ユーザーへの影響を起点に、何から手をつけるかを話せるようになります。 最初に置いた仮説が、正しいとは限りません。確かめてみると、想定とは別の場所で迷っていたり、課題だと思っていたことが実際にはそれほど影響していなかったりもします。 それでも、見ていた事実と仮説が共有されていれば、想定と違う結果が出たときに、次に何を確認するかを考えやすくなります。 事実は、提案を通すためだけの材料ではなく、チームで次の判断を下すための材料にもなります。 今回の事例を貫いていたのは、この考え方だったように思います。 参加者から寄せられた質問 イベント後のアンケートや質問フォームには、今回の内容を実践する際に迷いそうな点について、具体的な質問が寄せられました。たとえば、次のような内容です。 「売上を伸ばす」のような大きな目的から、どの粒度まで課題を小さくして調査を設計するのか アンケートで集めた声を、設問の意図や対象者を踏まえてどう読み取るのか 集めた事実を、聞き手が判断できる量にどう整理するのか また、「ユーザー中心の視点でサービス開発を進めるには、何から始めるとよいのか」「プロジェクト名など、普段使う言葉をユーザー起点に変えることにも意味があるのか」といった質問もありました。 内容を理解して終わるのではなく、自分の業務で試すとしたらどこで迷うのか。その段階まで踏み込んだ質問が多かったことが印象に残っています。ここで挙がった論点は、次回以降のテーマを考える際の材料にしていく予定です。 まず、手元にあるものを見てみる ユーザーファーストの実践というと、大がかりな調査や専門的なリサーチから始めるもののように感じるかもしれません。 今回の事例の起点は、オンライン相談やVoCなど、すでに手元にあった情報でした。そこから気になったことを、新入社員とのユーザビリティテストで確かめる。日々の業務で生まれる「このままでいいのかな」という違和感も、事実とセットにすると、チームで検討できる問いになります。 私自身、気になることがあると、つい解決策まで一気に考えてしまいます。今回の話を聞きながら、答えを出す前に、まず何が起きているのかを一度見てみることを忘れないようにしたいと思いました。 次に何かが気になったとき、まずは手元のログや問い合わせをひとつ確認してみる。今回のレポートが、そんな一歩につながればうれしいです。 関連記事 『ユーザーに寄りそわNight!』Vol.02レポート ── my route開発チームのフィールドワーク事例 KINTO Technologiesにおけるユーザーファースト推進の取り組み 定量データと定性データを行き来する ── ユーザーインタビューわいわい会

こんにちは。Engineering Officeのアクセシビリティアドボケート、辻勝利です。 普段使っているSlackに、ある時こんな投稿が流れてきました。 この投稿は、実際に流れてきた社内のお知らせと同じ構造で作った架空のメッセージです。以降の読み上げの引用と秒数は、すべてこの投稿を実測した値です。 目で見ると、気合いの入ったお知らせです。 NVDAというスクリーンリーダーで聴くと、こうなります。 クラッカー 絵文字ピカピカ 絵文字マイク 絵文字【募集】社内勉強会の登壇者を募集しますマイク 絵文字ピカピカ 絵文字クラッカー 絵文字　クラッカー 絵文字ピカピカ 絵文字マイク 絵文字クラッカー 絵文字ピカピカ 絵文字マイク 絵文字クラッカー 絵文字ピカピカ 絵文字マイク 絵文字クラッカー 絵文字ピカピカ 絵文字マイク 絵文字クラッカー 絵文字　ニテンリーダ なぜならば ニテンリーダ ニテンリーダ なぜならば ニテンリーダ ニテンリーダ なぜならば ニテンリーダ なぜならば ニテンリーダ なぜならば ニテンリーダ　来月の社内勉強会で話してくれる方を募集します。テーマは自由です。15 分の枠を 3 つ用意しています。（以下省略） 意味として受け取れるものは何もないまま音が続き、本文の最後の一文「迷っている方も、まずは気軽に声をかけてください。」を読み終わる頃には、2分31秒が過ぎていました。 1. スクリーンリーダーで読む、ということ スクリーンリーダーは、私たち視覚障害者が音声と点字で画面の情報を受け取るソフトウェアです。 基本的には、画面に表示されている内容を記号や絵文字を含めて一字一句そのまま読み上げるように設計されている支援技術です。冒頭のメッセージをNVDAで聴くと、何が起きているか。もう少し丁寧に辿ってみます。 フォーカスが投稿に当たった瞬間、読み上げが始まります。最初に届くのは「クラッカー 絵文字ピカピカ 絵文字マイク 絵文字」——タイトルの前に置かれた3つの絵文字です。そこを抜けてようやくタイトルの「【募集】社内勉強会の登壇者を募集します」に辿り着き、その後ろにも「マイク 絵文字ピカピカ 絵文字クラッカー 絵文字」が続きます。次の行は絵文字だけの装飾行で、13個ぶんの「クラッカー 絵文字」「ピカピカ 絵文字」「マイク 絵文字」が一つずつ読まれます。厄介なのはその次です。 ‥∵‥‥∵‥ のように記号が並んでいる箇所も一つひとつ読まれ、「ニテンリーダ なぜならば ニテンリーダ ニテンリーダ なぜならば ニテンリーダ ニテンリーダ なぜならば ニテンリーダ なぜならば ニテンリーダ なぜならば ニテンリーダ」と続きます。意味として受け取れるものは何もなく、思考を混乱させるような音だけが続きます。本文に入ってからも、小見出しのような行の前後に同じ3つの絵文字が挟まっているので、読み進めるあいだ何度も同じ音が割り込みます。ようやく最後の一文「迷っている方も、まずは気軽に声をかけてください。」に到達し、読み終える頃には、2分31秒が経っています。 目で見ると、装飾はメッセージの「気合い」や「テンション」として届きます。タイトルを目立たせ、絵文字で季節感を添える——投稿者の意図はきちんと伝わる、工夫された書き方です。一方、耳で聴く場面では同じ工夫が、本文の前に積み重なる、情報として届かない音として受け取られます。SlackでもMicrosoft Teamsでも、メッセージに絵文字や装飾が入っていれば、同じことが起きます。 情報の中身は変わらないのに、辿り着くまでの時間が変わる。 絵文字だけではありません。SlackやTeamsにXの投稿を含むなんらかのURLだけが投稿された場合、アプリがタイトル情報を取得できないと、NVDAは忠実にそのURLの文字列を読んでいました。画面にはリンク先の情報のプレビューが表示されているのにです。 「目で見る工夫」が「耳で聴く情報」になる場面では、届き方が変わる——それが、日常のチャットのなかで静かに起きていることです。 Slackは仕事のやり取りの大半が流れる場所です。そこで情報に辿り着くたびに時間がかかる——それが、日常の中で静かに積み重なっていました。 2. 1分29秒で届くようになった その違和感を解消するために作ったのが、NVDAアドオンの Message Sweeper です。 これまで私たちユーザーができることといえば、「スクリーンリーダーで読みづらいので、絵文字や記号の使用を控えてください」と投稿者にお願いすることでした。投稿者の表現の選択を制限する依頼です。Message Sweeper は、その構図を変えようとしています。投稿者が込めた「気づいてほしい」という意図はそのままに、スクリーンリーダーユーザーには読みやすい形で届ける——双方の意図が成立する場所を目指しました。 本音を言えば、読み上げのためにテキストを加工することは、あまり好きではありません。スクリーンリーダーは画面の情報をそのまま届けるために設計された技術であり、本来は発信側やアプリの側が変わることで解決されるべきものだと思っているからです。 それでも、仕事の現場には、その改善を待つ余裕がないほどの情報の波があります。できるだけ時間をかけずに処理しなければならない現実がある。Message Sweeper はその現実への応答です。だからこそ、発信する側と受け取る側、双方の歩み寄りがこれからも大切だと思っています。 同じメッセージを通すとこう届きます。 【募集】社内勉強会の登壇者を募集します 来月の社内勉強会で話してくれる方を募集します。テーマは自由です。15 分の枠を 3 つ用意しています。 こんな発表をお待ちしています （……中略……） メッセージの絵文字: クラッカー16こ、ピカピカ14こ、マイク14こ 情報を削るのではなく、再配置する。絵文字で気合いを入れてくれた投稿者のテンションは末尾のサマリーとしてちゃんと届き、本文は最初から順番に耳に入ってきます。2分31秒かかっていた読み上げが、1分29秒で届くようになりました。 読み上げが実際にどう変わるのかは、4分ほどの動画にもまとめています。読み上げの音そのものが本編なので、音を出して聴いてみてください。 https://youtu.be/1oQD78-KO7Q 動画は、公開版のMessage Sweeper 1.0.0で、冒頭に挙げたのと同じ架空の投稿を題材に撮影したものです。前半が処理をオフにしたときの読み上げで2分31秒、後半がオンにしたときの読み上げで1分29秒です。読み上げの速度も設定も、前半と後半で変えていません。 URLも同じです。Message Sweeper はリンクのURLをページタイトルに差し替えます。「エイチ ティー ティー ピー エス コロン スラッシュ スラッシュ...」と読まれていたものが、リンク先の内容として届くようになりました。URLだけが読まれていた頃は、ページを開いてみるまで、その情報が自分に関係あるかどうかさえわかりませんでした。ページタイトルが届くようになってから、今読むべきか、あとでいいか、読み飛ばしてもいいか——リンクを開く前に自分で判断できるようになりました。 変化は Slack だけにとどまりません。Teams を使う場面は主に音声会議で、会議中に参加者がチャットへリンクを貼ることがあります。話を耳で追いながら、URL文字列の読み上げが割り込んでくる——その状況は、Slack 以上に切実でした。Teams でも同じように整えて読み上げるようになって、使う道具が増えるたびに我慢が増えるのではなく、どのチャットでも同じ手触りで情報を受け取れる——その感覚が、思いのほか仕事のテンポを変えました。メッセージを開くたびに「今日はどれだけ長い読み上げが来るだろう」と身構えることがなくなり、流れてくる情報にそのまま乗れるようになりました。 NVDA+V で読み上げ処理のON/OFFをサッと切り替えたり、加工済みのテキストを点字ディスプレイにも同じ形で表示したりといった細部も、日常の中で少しずつ積み上げてきたものです。この機能群は、AIコーディング支援ツール Claude Code との共同作業で組み上がってきました。 3. 一人で開発していたら、仲間ができた 開発を進める中で、X（旧Twitter）のURLだけがどうしても取得できずにいました。Slack や Teams のメッセージやニュースサイトの情報は処理できるようになっていたのに、X のポストへのリンクが貼られると、中身が届かないまま読み上げられてしまう。そこで詰まっているとき、同僚の大園さんが「それなら手伝えるかもしれませんよ」と声をかけてくれました。 数日後、X のポスト取得を担当する PR が上がってきました。 竹中さんからはあるとき、冒頭に挙げたのと同じような装飾たっぷりのアドベントカレンダー募集の投稿について、こんなメッセージが届きました。 「アドベントカレンダーの募集メッセージ、普通に読み上げられると思ったら最悪の投稿ですね、いつも気付きをありがとうございます」 Message Sweeper がその投稿に対応できたとき、竹中さんはこう書き添えてくれました。 「いろんな人が全方位的に対応できる術を身につけて、誰かに負担を押し付けないのが大事だと実感させられました」 どちらも、こちらから求めたのではありませんでした。私が夢中で開発しているのを見て、興味を持ってくれたのです。 4. 職場で小さな循環が回り始めた 視覚障害のある知人がMessage Sweeper を使ってみてくれたとき、こんな言葉をもらいました。 「おかげで Slack を見てみる気になった。これまでは基本的に見ていなかった」 それだけで、作った甲斐があったと思いました。 その一連の流れを振り返ると、何かひとつの動きが見えてきます。当事者が作り、仲間が育て、別の誰かが使い始める。 この経験を、「配慮を求めない配慮」と呼びたい気持ちがあります。制度や義務として外から持ち込んだのではなく、日常の仕事の中で自然に育っていった——そういう感覚が残っています。その感覚が、私がこの記事を書きたかった理由でもあります。 その循環が、もっと広い場所でも起きてほしいと思っています。 Message Sweeper は、誰でもインストールして使えるかたちで公開しました。ソースコードも公開しているので、自分のメッセージに対して何をしているのかを確かめてから使えます。 リポジトリ: https://github.com/kinto-technologies/message-sweeper アドオンのダウンロード: https://github.com/kinto-technologies/message-sweeper/releases/latest インストールの手順、設定できる項目、動作を確認した環境は、リポジトリのREADMEにまとめています。不具合の報告や要望は、リポジトリのIssueで受け付けています。もしチャットツールの読み上げで「これは届きにくいな」と感じた体験があれば、ぜひ教えてください。

はじめに こんにちは、サイバーセキュリティと生成AI活用推進を担当しているたなちゅーです。 KINTOテクノロジーズ（以下、KTC）では、 以前の記事 で紹介した全社横断プロジェクト「AI-Native Dev」を中心に、AIネイティブな開発・業務プロセスへの変革を進めています。いまでは職種を問わず多くのメンバーが、日常業務のさまざまな場面でClaudeを利用しています。そうした環境の中で「パワーポイント作成もAI-Nativeにしたい」と考えるメンバーが現れ、それぞれがClaudeで利用しやすいパワポテンプレを自作するようになりました。こうした自作テンプレが社内で活発に使われている様子を目にしたことが、今回の取り組みを始める大きなきっかけです。 一方で、この動きには課題もありました。 自作テンプレは 個人ベース・非公式 にとどまり、社内に複数の様式が並行して存在している AI経由で生成したスライドの 見た目がバラバラで、会社の資料としての統一感が出ない そこで、これらの個人の創意工夫を束ねて、 「AIが利用しやすい会社公式パワポテンプレ」として一本化・全社展開する プロジェクトを立ち上げました。この記事では、その取り組みを紹介します。 取り組みの概要 目指した状態 プロジェクトのゴールはシンプルで、 「Claudeに指示するだけで、KTC公式デザインに揃ったスライドが出てくる」状態を全社員に提供する ことです。これにより、次の3つの価値を狙いました。 狙い 内容 時間短縮 資料作成をそのままAIへ渡せるようになり、作成時間を短縮できる デザインの統一 AI経由でも、見た目の揃ったKTCらしい資料になる 個人の取り組みの組織化 AI-Nativeな個人の創意工夫を、組織としての成果に引き上げる 3つ目が本プロジェクトの特徴的なポイントです。単にテンプレを作るのではなく、 すでに個人が生み出していたAI-Nativeな工夫を「会社公式」の標準にする ことを重視しました。AI-Native Devが文化醸成の軸として掲げてきた「個人の知見を組織全体で活かす」を、パワポテンプレという誰にとっても身近な題材で実践した形です。 体制と進め方 推進はAI-Native Devが担い、テンプレートのデザインはクリエイティブグループが担当する協業体制で進めました。今後は技術広報グループとも連携しながら、利用促進に取り組んでいく予定です。 全体像は次のとおりです。 進め方として特に大事にしたのは、次の合意です。 「AIで再現しやすいフォーマット / スタイルガイドはどうあるべきか」を AI利用者側から逆算してデザイナーへインプット し、デザイナーがそれを受けてフォーマットを設計する。 デザインが完成してからAIに対応させるのではなく、設計の段階から「AIが出力しやすい構造」を要件に含めています。この取り組みを「AI-Native」と呼んでいるのは、こうした進め方によるものです。 フェーズは次のように区切りました。 フェーズ 内容 Phase 0 パワポテンプレへの期待値整理 Phase 1 たたき台テンプレの社内展開 & フィードバック収集 Phase 2 公式テンプレの作成と、AIが利用しやすい形（コンポーネント化・スキル化）への変換 Phase 3 全社アナウンス Phase 4 利用者ヒアリングと継続的なメンテナンス いきなり完成品を作るのではなく、まず有志の自作テンプレをたたき台として展開してフィードバックを集め（公開後50名以上が閲覧・ダウンロード）、その声をもとに公式版を作る、という2段階を踏んでいます。 AIが利用しやすいテンプレートの設計 完成したテンプレートには、AIとの相性を高めるための工夫がいくつも入っています。 ヘッダー＋ボディのコンポーネント構造 スライドを「ヘッダー＋ボディ（シングル / スプリット / マルチカラム）」というコンポーネントの組み合わせとして構造化しました。AIは自由なレイアウトを毎回ゼロから作るよりも、 決められた部品の組み合わせを選ぶ方が安定して高品質な出力を返せる ためです。 レイアウト選択ルールのスキル化 「どんな内容のときに、どのレイアウトを選ぶべきか」というルールをClaudeのSkill（スキル）として整備しました。これにより、毎回テンプレファイルを渡さなくても、Claudeが自律的に適切なレイアウトを選択してスライドを組み立てられます。 使い方は3通り 展開にあたっては、作業スタイルに合わせて3通りの使い方を用意しました。 利用方法 向いている人・場面 方法1：テンプレPPTXをClaudeへ渡す まず試したい人。PowerPointでの手動編集も併用したい人 方法2：Skillを使う 資料作成の頻度が高い人。毎回ファイルを用意する手間をなくしたい人 方法3：Claude Designを使う 見た目を対話しながら細かく詰めたい人。1枚ものやビジュアル重視の資料 方法1は、Claude Coworkやチャットにテンプレファイルとアウトラインを渡して「このテンプレを踏襲して」と依頼する、いちばん手軽な入口です。 方法2のSkillにはテンプレのデザイン情報が組み込まれているため、社内のプラグインマーケットプレイスから一度インストールすれば、ファイルを用意しなくても依頼するだけで公式デザインの資料が生成されます。 方法3のClaude Design向けには、配色・フォント・レイアウトを定義したデザインシステム（ダーク・ライトの2トーン）を用意しました。pptxファイルとして配布・編集したい資料は方法1・2、見た目の作り込みを優先したい資料は方法3、という使い分けです。 「迷ったら方法1から」という導線にして、AIでの資料作成に馴染みのない社員でも一歩目を踏み出しやすくしています。 おすすめの進め方は「先にアウトラインを固める」 どの方法でも共通して案内しているのが、 いきなりpptxを作らせず、先にClaudeと壁打ちしてアウトラインをMarkdownで固める 進め方です。生成されたpptxに「2枚目を直して」「構成を変えて」と修正を繰り返すと、そのたびにファイルの再生成が走り、時間もトークンも大きく消費します。内容の試行錯誤はMarkdown上で済ませ、pptxの生成は最後の1回だけにすることで、トークン消費を大きく抑えられます。 また、生成された資料の数値・固有名詞・事実関係は必ず人の目で確認する、という運用もあわせて案内しています。テンプレ自体も作って終わりではなく、利用者へのヒアリングやフィードバックフォームを通じて、レイアウトの追加なども含めて継続的にブラッシュアップしていく予定です。 おわりに 「AIに指示するだけで、会社公式デザインのスライドが出てくる」のは、使ってみるとシンプルに便利です。そして、それを実現する鍵は高度なAI技術ではなく、 AIが扱いやすい形にテンプレートという「型」を設計し直すこと 、そして その型をデザイナーとAI利用者が一緒に作ること でした。デザインルールをどこまで厳密に縛り、どこを緩めるかの塩梅も、この過程で見えてきた収穫です。 個人の創意工夫として始まったAI-Nativeな動きを、組織の公式な成果に引き上げる。このモデルはパワポテンプレに限らず、さまざまな社内資産に適用できるはずです。この記事が、同じような取り組みを検討している方の参考になれば嬉しいです。 AI-Native Devの活動やナレッジは、引き続きテックブログで発信していきます。最後まで読んでいただきありがとうございました！

この記事でわかること 2026年7月31日、KINTOテクノロジーズ（以下、KTC）のOsaka Tech Lab JCTを会場として、Anthropic公認のコミュニティイベント「Claude Managed Agents Workshop」が開催され、約30名が参加しました。主催はClaude Community Ambassadorであり、KTC社員でもある森田さんです。 Claude Managed Agentsは、エージェントを動かすための土台（実行制御・サンドボックス・履歴やファイルの保持）をAnthropic側が用意してくれるサービスです。利用者はエージェントの設定とメッセージの送信に集中できます。 ワークショップの教材は誰でも参照できる形で公開されています。イベントに参加していなくても、同じ手順でエージェントを作って動かせます。 ハンズオンで唯一つまずいたのはClaude側ではなく、外部サービスであるJina AIのAPIキーでした。キーに無料トークンが残っているとは限らないので、教材を試す前に残トークンを確認しておくと足を止めずに進められます。 はじめに こんにちは、KINTO開発部でフロントエンドエンジニアをしている 齋藤 です。普段はKINTOのシミュレーションや申し込み、マイページの開発を担当しています。 2026年7月31日（金）、KTCのOsaka Tech Labを会場として、 Claude Community Event「Claude Managed Agents Workshop」 が開催されました。私は会場提供・運営サポートを担当しつつ、参加者としてハンズオンにも取り組みました。 本記事は、その開催報告です。  当日のエントランスの様子 開催したイベントの概要 項目 内容 イベント名 Osaka | Claude Managed Agents Workshop （Claude Community Event） 開催日 2026年7月31日（金）18:30〜21:05 会場 KINTOテクノロジーズ Osaka Tech Lab JCT（大阪市北区梅田3-1-3 ノースゲートビルディング20階） 主催 森田さん（Claude Community Ambassador） 会場提供 KINTOテクノロジーズ 参加者 約30名 タイムテーブルは次のとおりです。 時間 内容 18:30〜19:00 受付・交流 19:00〜19:10 オープニング・会場説明 19:10〜19:30 Claude Managed Agentsの解説 19:30〜20:45 ハンズオン（個人ペース） 20:45〜21:00 ネットワーキング 21:00〜21:05 クロージング 会場提供の経緯 主催の 森田さん は Anthropicから認定されたClaude Community Ambassador であり、同時にKTCのPrincipal Generative AI Engineerでもあります。社内向けのAIエージェント構築ワークショップを開催した話は、 こちらの記事 で紹介されています。 今回のイベントは、その森田さんが場所貸しイベントとして社内で起案し、運営協力者の募集がかかったところに私が手を挙げた、という流れで実現しました。 会場：Osaka Tech Lab JCT Osaka Tech Labは、東京・名古屋に次ぐKTCの第3の拠点です。2022年に心斎橋で開設され、2025年夏にJR大阪駅直結のノースゲートビルディングへ移転しました。「集GO！発SHIN！CO-LAB」というコンセプトを掲げていて、会議室にGARAGEやPIT、モータープールといった車にちなんだ名前が付いていたり、執務室の床がレーシングラインを模した遊び心のあるデザインになっていたりします。 今回使用した Osaka Tech Lab JCT は、その20階にあるイベントスペースです。40名ほどを収容できる広さで、今回の参加者は約30名でした。JR大阪駅直結という立地なので、金曜夜のイベントでもアクセスしやすい会場です。 アクセス方法は KINTOテクノロジーズOsaka Tech Labにご来場のかたへ で写真つきで案内しています。 当日の様子 当日は、Anthropicでコミュニティ活動を担当されている 辻さん にもご来場いただき、会の冒頭にご挨拶をいただきました。大阪でのアンバサダー主催イベントは今回が初めてであること、今後も関西でコミュニティを盛り上げていきたいというお話をされていました。 続く30分は、森田さんによるClaude Managed Agentsの解説パートです。  解説パートの様子。スクリーンに投影されているのが当日使用した教材です その後はハンズオンに移ります。各自のペースで進める形式だったので、全員が黙々とキーボードを叩いている時間と、手が止まった人が周りに聞いて質問が飛び交う時間が、交互に訪れていました。 各テーブルにはお菓子が用意されていて、つまみながらハンズオンを進められました。  ハンズオン中の会場。各自のペースで進めます もくもくと作業が進むなか、森田さんが会場を回って、困っている人がいないか声をかけてサポートに入る場面もありました。 手を挙げれば主催者が直接見に来てくれる という体制だったので、普段Claude Codeを使っていない人でも安心して参加できるイベントだったと思います。  サポートに入る森田さん 参加者の年齢層は幅広く、学生の方も参加されていました。  Osaka Tech Lab JCTは40名ほどを収容できます 参加者には、Claude Managed Agentsを試すための$50相当のAPIクレジットが配布されました。 さらに辻さんからは、Anthropic公式のノベルティも提供していただきました。  Claude Codeのマスコットキャラクター「Clawd」のぬいぐるみ。サングラス姿と、白衣にフラスコを持った科学者姿の2種類がありました  M5Stack Cardputer ADV 数に限りのあるノベルティは希望者が用意された数を上回ったため、 じゃんけん大会 でもらえる人を決めました。会場が一番盛り上がった瞬間だったかもしれません。  じゃんけん大会の様子  最後に参加者の皆さんと。手にしているのがClawdのぬいぐるみです Claude Managed Agentsとは ここで、当日のテーマだったClaude Managed Agentsについて、私が理解した範囲で整理しておきます。 AIエージェントを自分でゼロから作ろうとすると、アプリケーション側で用意しなければならないものが意外と多くあります。モデルを呼んでツールを実行し、その結果をまたモデルに渡す、という繰り返しの制御。ツールを安全に動かすための実行環境。途中で生成されたファイルや会話履歴の保持。Claude Managed Agentsは、この土台をAnthropic側がまるごと用意してくれるサービスです。利用者が用意するのは「どんなエージェントにするか」という設定と、「何をしてほしいか」というメッセージだけになります。 Messages APIとの棲み分けは、公式ドキュメントでは きめ細かい制御が欲しいならMessages API、数分から数時間かかる長時間実行タスクや非同期処理ならClaude Managed Agents という整理になっています。 登場する概念は4つです。 概念 何を指すか エージェント 使うモデル、システムプロンプト、ツール、MCPサーバー、スキルをまとめた設定。一度作ればIDでセッションから参照できる 環境 エージェントを走らせる場所。Anthropic側のクラウドサンドボックスと、自分たちで管理するインフラ上で動かすセルフホスト型が選べる セッション 環境の中で実際に動いているエージェントの実体。タスクを実行して成果物を残す イベント アプリケーションとエージェントのあいだで交換されるメッセージ。ユーザーの指示、ツールの実行結果、ステータス更新などが該当し、レスポンスはSSEでストリーミングされる ハンズオンも「エージェントを作る → 環境を作る → セッションを起動する → メッセージを送る」という順番をそのままたどる構成になっていたので、この4つの関係は手を動かしているうちに自然と頭に入りました。 サンドボックスの中では、bash、ファイルの読み書き・編集、glob・grep、Web検索・取得といったツールが最初から使えます。ここにMCPサーバーを繋げば外部サービスのツールも呼び出せる、という組み立てです。 料金は次の2軸です。 セッションのなかでモデルが使ったトークンぶんの、通常のAPI料金（プロンプトキャッシングの乗数も同じように適用されます） セッションランタイム（セッション時間あたり$0.08） セッションランタイムはミリ秒単位で計測され、セッションが running のあいだだけ加算されます。次のメッセージを待っている idle の時間は加算されません。裏を返せば、 エージェントを長時間放置しても待機中のコストは増えない ということで、これは長時間タスク向けという位置づけと整合しています。なお、セッション内でWeb検索が走った場合は1,000検索あたり$10が別途かかります。 本記事執筆時点でClaude Managed Agentsはベータ版です。詳細は 公式ドキュメント と 料金ページ を参照してください。 ハンズオンをやってみた 私は受付を担当していたため、ハンズオンの開始が少し遅れました。さらにイベントの様子を撮影しながら進めていたので、上級には届かず 中級まで の到達です。 教材は初級・中級・上級の3段階構成になっていて、内容は次のようなものでした。 初級 ：テンプレート「Deep researcher」からリサーチエージェントを作る、チャットで設定を自動生成してMicrosoft LearnのMCPサーバーを使うクイズエージェントを作る、自由演習 中級 ：Jina AIのMCPサーバーにつながるWebリサーチエージェントを、 コンソール・CLI（ ant ）・Python SDK の3通り で作る 上級 ：分析レポート（スライド生成）、スケジュール実行でGitHub Pagesを毎朝更新、Gmail連携、記憶するエージェント、マルチエージェント 同じエージェントをコンソール・CLI・SDKの3通りで作らせる中級の設計が特に良くできていて、画面操作で理解した概念がそのままAPIのリソース構造に対応していることが体感できました。 そして特筆すべきは 教材の完成度 です。説明が丁寧で画像も豊富に用意されていて、公式が提供した教材と言われても遜色ないなと感じる内容でした。おかげでClaude Managed Agentsの部分ではまったくつまずくことなく進められました。 つまずいたのはJina AIのAPIキー 強いて挙げるなら、中級で使う Jina AIのAPIキー が唯一の詰まりどころでした。私のAPIキーには無料トークンの残りがなく、Jina AIのツールを呼び出せませんでした。 中級で作るのはWeb検索するリサーチエージェントで、検索は Jina AI の MCPサーバー 経由で実行します。この検索系のツールはAPIキーが必須です。APIキー自体はアカウント作成もクレジットカード登録もなしにトップページから取得できるのですが、 そのキーに無料トークンが残っているとは限りません 。 :::message これから教材を試す方は、先に jina.ai の「API KEY & BILLING」タブでAPIキーの残トークンを確認しておくと、中級で足を止めずに進められます。 ::: イベントに参加していなくても教材を試せます このワークショップの教材は、森田さんが作成したものが公開されています。 Claude Managed Agents Workshop（教材サイト） イベントに参加していなくても、事前準備から上級まで同じ手順をたどれます。Claude Managed Agentsを触ってみたい方には、公式ドキュメントを読み込むより先にこちらを一周するのがおすすめです。 :::message この教材はAnthropicの公式コンテンツではなく、非公式の学習教材です。ライセンスがCC BY-NC-ND 4.0のため、本記事では中身の転載はせず、リンクの紹介にとどめています。 ::: 8月にも同じ内容のワークショップが開催されます 今回のイベントは申込がキャンセル待ちまで伸び、参加できなかった方が多く出ました。そうした方に向けて、 同じ内容のワークショップが8月にも開催されます 。 項目 内容 イベント名 Osaka | Claude Workshop 開催日 2026年8月18日（火） 会場 クラスメソッド株式会社 大阪オフィス（大阪市中央区伏見町3-6-3 三菱UFJ信託銀行大阪ビル8階） 主催 森田さん（Claude Community Events） 解説のあとハンズオンという流れは7月31日と同じ構成です。申込には承認が必要なので、詳細は イベントページ を確認してください。 おわりに Claude Managed Agentsは、エージェントの設定とメッセージの送信だけで自律エージェントを動かせるプラットフォームです。教材が公開されているので、興味を持たれた方はぜひ手を動かしてみてください。 Osaka Tech Labでは今後もイベント開催を予定しています。 KINTOテクノロジーズのconnpass もあわせてチェックしていただけると嬉しいです。 参考リンク Claude Managed Agents Workshop（当日使用した教材） Claude Managed Agentsの概要（公式ドキュメント） Jina AI 公式MCPサーバー 社内でAIエージェント構築ワークショップを開催しました。（森田さんの記事） KINTOテクノロジーズOsaka Tech Labにご来場のかたへ

はじめに こんにちは、2026年5月入社のyaMayuです！ 本記事では、2026年5月に入社したメンバー2名に入社直後の感想をお伺いし、まとめました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加してくださったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ Y.Q 自己紹介 グループコアシステム部　ビジネスディベロップメントGに配属されました。 自動車部品メーカー→ITコンサル→当社　といったキャリアを歩んでいます。 所属チームの体制は？ グループコアシステム部の人数が多いですが、ビジネスディベロップメントGは割と少数精鋭です。（現在6人） 同じグループのメンバーは出身地が多様で（欧州、北米、アジアetc.）グループ内の公用語は英語です。 KTCの入社動機や入社前後のギャップは？ トヨタグループとしての安定感と、若い会社らしいベンチャーカルチャーの両方に魅力を感じたこと、またモビリティサービス領域でのビジネスディベロップメントに携わりたいと考えたことが入社の動機です。 今のところ、大きなギャップは感じていません。 現場の雰囲気はどんな感じ？ 真面目な雰囲気とフラットな雰囲気の、良いバランスが取れていると感じます。 オフィスで気に入っているところ Water Serverがある。 周りにランチできるお店が多い。（立地） yaMayuさんからの 質問：旅行が趣味とのことなので、おすすめの場所やまた行きたい場所があればお伺いしたいです！（日本国内でも、海外でもどちらでもOKです！） 小笠原諸島です！片道1日ほどかかる長い船旅を経て訪れる分、非日常な体験が待っていました（ウミガメの産卵ツアーもおすすめです！）。太平洋に浮かぶ夜の星空や朝日にも感動し、また訪れたいと思っています。 yaMayu 自己紹介 プラットフォーム開発部 Quality Engineering GでQAエンジニアをやっています。 異業種からSESに転職し、第三者検証を経てKTCに入社しました。 京都市出身で今は都内在住、室町オフィス勤務です。 趣味と呼べるものはあまりないですが、移動中はよくオーディオブックを聴いています。読書も好きです。ミステリー多めです。たまに映画を観に行ったりします。 所属チームの体制 Web QA, アプリQA, SETチーム合わせて21名です。 6月にSETチームが新設され、大幅に人が増えました。 QA, SETチームとも室町オフィスとOsaka Tech Labにメンバーがいます。 私はWeb QAチームに所属しています。 現場の雰囲気 大阪のメンバーとは拠点が離れていますが、Slackやzoomで随時連絡や相談をしています。 オフィスに出社しているときは、一緒にランチ行くこともあり和やかな雰囲気だと思います。 KTCへの入社動機や入社前後のギャップ 前職、前々職ではお客様先のプロダクトに携わっていたので、自社プロダクトのQAに携わりたいと思い、転職しました。 プロダクトのジャンルはあまり絞っていなかったのですが、サブスクサービスはいろんなジャンルでどんどん広まっているので、今後も需要がありそう ＝ 多くの人に使ってもらえるプロダクトに携われそう、と思い入社しました。 カジュアル面談～面接～オファー面談でいろいろお話を聞くことができていたので、入社後の大きなギャップは今のところないです。 オフィスで気に入っているところ 地下鉄の駅から直結なので、雨でも濡れない＆日差しも怖くないところ。 周辺においしいお店が多いところ。（お値段は安くはないですが…。） フリードリンクでコーヒーが飲めるところ。 Y.Qさんからの質問：京都出身者として、観光客があまり知らないおススメの場所や楽しみ方をご教示ください！ 最近はネットやSNSですぐ広まってしまうので難しいですね…笑 志津屋のカルネ：もうすっかり有名になってしまいましたが、昔から好きで、今も実家に帰ると必ず食べます！ 法輪寺 電電宮：電気・電波の神様を祀る神社です。（日本唯一らしいです！）IT関連の人にも人気があります。嵐山にありますが、渡月橋から少し離れているので比較的空いていると思います。 明智越：明智光秀が愛宕神社に参詣する際に通った道で、本能寺を攻める際にも通ったと言われています。今はハイキングコースになっていて、歴史と自然を感じられます。（台風や豪雨の影響で道が荒れている場合もあるようなので、訪れる際はご注意を。） さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

はじめに こんにちは、2026年4月入社の山本です！ 本記事では、2026年4月入社メンバーに入社直後の感想をお伺いし、まとめてみました。 前の方からの質問に次の方が答えるリレー形式でお届けします。 KINTO テクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ もっさん  自己紹介 KINTO開発部 開発推進Gに所属しています。 案件全体の管理や、AIを活用したサイト構築のプロジェクトを担当しています。 スポーツ観戦が趣味で、最近は地元のBリーグクラブを応援しています。せっかくなのでKINTOと縁のあるアルバルク東京もこれから推していきたいです！ 所属チームの体制は？ 開発推進Gは8名体制で、KINTOサービスに関わる開発案件のプロジェクトマネジメントを主に行っています。 職種はPMが中心で、事業部側のメンバーや開発メンバーと連携しながら、ものづくりを進めています。 KTCへ入社したときの第一印象は？ギャップはあった？ 前職の同僚が在籍していたこともあり、入社前から気軽に質問でき、カジュアル面談でも疑問をその場で解消できたので、不安なく入社できました。 入社後はフットサルや筋トレなど、いろいろな活動を楽しんでいるアクティブな方が多く、いい意味でのギャップを感じました。 エンジニアの勉強会など学びや発信の場が多いのも印象的で、自分の経験がない分野でも興味があれば気軽に参加させてもらっています。 現場の雰囲気はどんな感じ？ 休憩室では豆を挽いてコーヒーを淹れている方がいて、香りにつられてふらふらと混ざりに行きました。とてもウェルカムな雰囲気で、業務でまだ関わりのない方ともゆるく繋がれるのがありがたいです。 全員が中途採用ということもあり各分野のプロフェッショナルが揃っていて、日々の会話から多くの刺激をもらっています。 オフィスで気に入っているところ 室町オフィス勤務です。 オフィスから日本橋をわたって八重洲・銀座あたりを歩くのがお気に入りで、街のにぎわいを感じながらの散歩がいい気分転換になっています。 寿司と紅茶さん ⇒ もっさんへの質問 生まれ変わったらなりたい職業とその理由を教えてください 料理人やパティシエですね。今はチームでものづくりをしていますが、生まれ変わったら一人で黙々と何かを突き詰めてみたいです！ つじたく  自己紹介 新サービス開発部 FACTORY EC開発G所属です。 趣味は筋トレです。体を大きくしたいです。 所属チームの体制は？ 新サービス開発部 FACTORY EC開発Gで、TOYOTA/LEXUS UPGRADE FACTORYのEC基盤を開発・運用しています。 フロントエンド、バックエンド、PdM、SRE、QA、ディレクター、マネージャーなど合わせて15名ほどの体制です。 KTCへ入社したときの第一印象は？ギャップはあった？ 入社前の面接の時も色々話をしていたので大きなギャップはなかったです！ 現場の雰囲気はどんな感じ？ フロントエンド、バックエンド、PdMなど各方面のメンバーが揃っているので提案→実行までが素早くできて働きやすいです。 オフィスで気に入っているところ 駅から近く、改札出てから5分もたたずに自席に座れるところ。 オフィスが綺麗なところ。 もっさん ⇒ つじたくさんへの質問 TOYOTA UPGRADE FACTORY 担当されていますが、こんなアップグレードあったらいいなと思うのはどんなものですか？ 自分の運転スタイルを学習して、燃費・快適性のバランスを自動最適化するAIモードみたいなアップグレードがあったらいいなと思います。 山本雄太  自己紹介 新サービス開発部 プロジェクト推進グループ所属の山本雄太です。ロールはPjMです。 仕事は寄り添い伴走するようなスタイルが性に合っており、誰かの為にだとより力が出るタイプ。 趣味はゴルフ・釣り・サウナ・キャンプなどアクティブ系広め、お酒も大好きです。最近はゴルフにハマってます。やっと100を切りはじめました！ 所属チームの体制は？ プロジェクト推進グループは10名にも満たない小規模体制ですが、トヨタグループ各社に対してKTCの技術力を活かして支援を主導するグループでもあり、やりがいは大きいです。 最先端な取り組みにも関与できるチャンスがあるので、KTCの中でも一番面白いグループなのではとも思っています。 KTCへ入社したときの第一印象は？ギャップはあった？ 第一印象は…オフィスがどの拠点も立派！笑 ギャップは想像以上にスキルフルなメンバーが多い点です。 現場の雰囲気はどんな感じ？ 少数チームという性質もあり、各自別のプロジェクトで作業しており実質的な関わりは少ないです。 ただ、定例MTGは情報交換が活発に行われており、相互に助言できる程よい雰囲気に感じます。 オフィスで気に入っているところ 私はFukuoka Tech Lab所属で、大名のリッツ・カールトンの真下にオフィスがあり景色が良い！博多湾を一望できて、天気が良い日には志賀島や能古島も綺麗に見える窓際がお気に入り、良いリフレッシュゾーンになっています。 つじたくさん ⇒ 山本さんへの質問 おすすめの日本酒教えてください！ 福岡は酒蔵が意外と多くて迷いますが、寒北斗をおすすめします！ 北斗七星をモチーフにしたパッケージやお猪口もあったり、見た目から愛せます。 寿司と紅茶  自己紹介 デジタル戦略部データグロースGでマネージャーをしています。 Webエンジニア → EM・PdM → 事業責任者 → VPoE といったキャリアを歩んでいます。 所属チームの体制は？ 1チームに機能横断している方々が揃っているのが特徴です。 PdM、エンジニア、デザイナーといったプロダクトトリオが揃っているため、多角的な視点から機能改善や案件進行ができるのが強みです。 KTCへ入社したときの第一印象は？ギャップはあった？ リファラルなので事前に質問できていた点とカジュアル面談も複数回実施させていただいたため、ギャップはありませんでした。 現場の雰囲気はどんな感じ？ 比較的スタートアップのようにワイワイやっている雰囲気が強いですね。 会社規模で考えると総合的に珍しいかもしれません。 オフィスで気に入っているところ フリードリンクが用意されているところ、宅配弁当が頼めるところですね。 山本さん ⇒ 寿司と紅茶さんへの質問 これまでで一番歯ごたえのあった仕事はどんな仕事でしたか？ ゼロから開発組織を作ることになり、未経験から採用要件、スカウト業務、AG対応、カジュアル面談、面接、オファー対応などすべてやってました。 さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

こんにちは！ Principal Generative AI Engineerの森田です。私の所属するAIファーストGでは、社内の生成AI活用にとどまらず、販売店やトヨタグループにおけるAI活用支援を行っております。 社内でAIエージェントの活用が進む中、ある部署から「AIエージェント開発に取り組みたいが、どこから始めていいかわからない」と相談をもらいました。座学だけでは手触り感が得られないので、実際に手を動かすワークショップ形式で開催することにしました。 弊社はAWSを主なクラウド基盤としているため、AWSが提供するAIエージェントの構築・運用基盤である Amazon Bedrock AgentCore と、エージェントのツール連携プロトコルである MCP（Model Context Protocol） を中心テーマに据えました。 教材として使用した書籍 ゼロから資料を作るよりも、体系的にまとまった書籍のハンズオンをベースにした方が、参加者が後から復習しやすいと考えました。今回は以下の2冊を使用しています。 『 Amazon Bedrock AgentCore 実践入門 ── Strands Agentsで構築するAIエージェント 』 （SBクリエイティブ）　※以下、AgentCore本 『 AWSではじめるMCP実践ガイド ── 基礎からAIエージェント構築まで徹底解説 』 （技術評論社）　※以下、MCP本 AgentCore本でエージェントフレームワークであるStrands AgentsやAgentCoreの各機能を学び、MCP本でMCPサーバーの自作とAgentCore Gatewayによるツール統合を学ぶ、という組み合わせです。 実は、どちらも私が共著者として執筆に携わった書籍です。手前味噌で恐縮なのですが、中身を隅々まで把握できている分、参加者がハンズオンで詰まったときにも補足しやすく、教材として選びました。 開発環境 今回は環境を揃えるため、 GitHub Codespaces 上に開発環境を用意しました。書籍の手順をベースに、以下の工夫で環境構築にかかる時間を短縮しています。 ツール管理は mise に統一し、 mise use aws-cli node uv claude でAWS CLI・Node.js・uv・Claude Codeを一括導入 AWSへは aws configure sso でSSOログイン コーディングのお供として Claude Code をセットアップ サンプルコードは書籍著者が公開しているGitHubリポジトリを git clone して参照できるようにし、すべてのコードを手打ちしなくていいようにしました。 ワークショップの構成 1日のワークショップとして、午前・午後に分けて以下の流れで進めました。 午前の部（1.5時間）・・・Strands Agentsに触れる # タイトル 書籍・該当箇所 概要 1 Strands Agents入門 AgentCore本 3.4節 ツール定義、エージェント作成、会話ループの実装など基本を体験 2 リサーチエージェントの構築 AgentCore本 4章 Webから情報収集・要約するエージェントを構築し、ツール連携の開発フローを掴む 任意 AgentCoreハーネス AgentCore本 5.2節 時間に余裕がある人向けに、AgentCoreハーネスを体験 午後の部（3時間）・・・AgentCoreとMCPを実践する # タイトル 書籍・該当箇所 概要 3 AgentCoreランタイム入門 AgentCore本 5.3節 agentcore create → agentcore deploy でエージェントをクラウドにデプロイ 4 アンビエントエージェントの構築 AgentCore本 15章 S3への領収書アップロードをトリガーに、解析→Confluence記録→メール通知するイベント駆動型エージェントをCDKで構築 5 MCPサーバーの構築 MCP本 4.2節 自前のMCPサーバーとホストを実装 6 AgentCore Gateway MCP本 6.2節 MCPサーバーをAgentCore Gatewayに登録し、認証・認可を統合 社内実施にあたって変更が必要だったポイント 書籍のハンズオンをそのまま社内で実施するにあたり、いくつか環境差異への対応が必要でした。 :::message メールアドレスのエイリアス 15章のアンビエントエージェントでは、サンプルデータ内の複数ユーザーのメールアドレスにそれぞれ通知を送る設計になっています。しかし社内のメール環境ではエイリアスが使えなかったため、 data/users.json のメールアドレスをすべて自分のアドレスに統一しました。その結果、同じアドレスでSNSサブスクリプションが重複してしまうため、 chapter15/cdk/lib/expense-agent-stack.ts で重複を排除するよう修正しました。 + const uniqueEmails = [...new Set(emailAddresses)]; - emailAddresses.forEach((email, i) => { + uniqueEmails.forEach((email, i) => { // 各アドレスごとに SNS サブスクリプションを作成 }); ::: :::message Googleカレンダー連携が使えない環境 13章のフルスタックエージェント構築ハンズオンはGoogleカレンダー連携（Google認証）を前提としているため、社内環境では実施が難しく割愛しました。興味がある方には自宅での実施を案内しています。 ::: :::message AWSアカウントの共有 複数人で1つのAWS環境を使ったため、リソース名が他の人と重複・混同しないよう、各自の名前を付与するルールにしました。特にS3バケット名はアカウント内で一意である必要があり、そのままだと衝突してしまいます。CDKスタックにハードコードされたバケット名（ expense-agent-${account} ）に自分の名前を付けて回避しました。AgentCoreランタイムも、 agentcore create で付ける名前を handsonmorita のように各自で区別できるものにしています。 ::: :::message alert リージョンの差異 AgentCore本とMCP本で、使用リージョンが異なっているため、単一リージョンで実施するには読み替えが必要でした。GitHubで公開されているサンプルソースを利用して進めていたのですが、どこを修正すればよいかが見落としやすいポイントでした。 ::: 参加者からもらった質問 ワークショップ中、参加者からいくつか印象的な質問がありました。 Q. ツールの定義はPythonでもできるのか？ Strands Agentsのツール定義はPythonのデコレータ @tool で行えます。関数のdocstringがそのままツールの説明文（description）としてLLMに渡されるため、Pythonで完結します。MCPサーバーとして公開する場合もPython SDKが利用可能です。 Q. Swarmエージェントはどうやってタスクを振り分けているのか？ マルチエージェント構成（Swarm）では、オーケストレーターとなるエージェントがLLMの判断に基づいて、各サブエージェントにタスクをルーティングします。各エージェントのnameやdescriptionに基づき、他のエージェントの役割を把握したうえで、作業を委譲するエージェントを選択します。 Q. マルチエージェントにするか、シングルエージェントにするか、どのように決めるのが良いか？ 個人的な感覚としては、最初から厳密に切り分けようとしない方がうまくいきます。シングルエージェントとして作り始めて、複雑なタスクをうまく処理できなくなったり、コンテキストを分けた方が動きが安定すると感じた時点で、サブエージェントへの分割を考える、というのが実際の進め方に近いです。 Q. エージェントで使用するモデルはどのような基準で選んでいるのか？ コストを最初から意識しすぎないことが大事だと思っています。Sonnetをベースにまず作ってみて、判断の精度が足りない部分はOpusに切り替え、単純作業の部分だけHaikuでコストを下げる、という順番です。先にHaikuでコストを抑えようとすると、実現できる機能のレベルが下がってしまうので、まずは「エージェントとして実現できるか」を確認してから、コスト最適化に移る方がスムーズに進みます。 参加者の声 ワークショップの締めに参加者で「振り返り会」を行い、そこで出た声の中から印象的だったものをいくつか紹介します。 ある参加者は、「エージェントの動きが、これまでふんわりとマジックのように感じていたのに、こういう仕組みで動いていたのかと腹落ちした」と話してくれました。難しさの本質はプロンプトの作り込みにある、という気づきを得られたようです。 別の参加者は、ハーネスの手軽さに驚いたそうです。テンプレートに「あなたはプロ野球に詳しい人です」のような一行を書くだけでエージェントが動いてしまうのを見て、拍子抜けするほど単純だったと話していました。 MCPサーバーの自作に取り組んだ参加者は、午後の中でも特に難しかったと振り返っていました。それでも自分の手で実装したことで、普段使っているMCPの裏側の動きまで想像できるようになった、という言葉が印象的でした。 これまで固定パイプライン的な実装（情報を取得し、LLMに渡し、整形して出力する）に慣れていたという参加者は、エージェントが入力に応じて処理のルートを動的に決めていく発想自体が新鮮だったと語っていました。同じ入力でも出力のパスが事前に決まっていない、というところに面白さを感じたそうです。 ワークショップを終えて 1日にかなりの内容を詰め込んだこともあり、進み具合には個人差が出ました。午前の任意項目だったAgentCoreハーネス（5.2節）まで到達できた方もいれば、そこまで手が回らなかった方もいます。午後はそれぞれの興味に合わせて、アンビエントエージェントに取り組むグループとMCPサーバー構築に取り組むグループに分かれて進めてもらいました。 今回のワークショップを通して、書籍のハンズオンをベースにしたことで準備の負担を抑えつつ、実践的な内容を届けられたのは良かったです。本記事が、これからAIエージェント開発に取り組む方や、同様のワークショップを企画する方の参考になれば幸いです。最後までお読みいただき、ありがとうございました。

こんにちは! KINTOテクノロジーズ(以下、KTC)のAIファーストグループで、生成AIの活用推進を担当している和田です。 先日、JDLA(日本ディープラーニング協会)の資格合格者コミュニティ「CDLE」の業種別勉強会にお招きいただき、「個人の発見を、組織の知恵に」というテーマで登壇してきました。本記事は、その内容を再構成したものです。 https://jdla.connpass.com/event/393970/ 1. はじめに KTCはトヨタ自動車のグループ会社で、クルマのサブスク「KINTO」をテックの力で支える内製開発の会社です。 2023年の春、GPT-4とAPI版が出てきたタイミングで内製の生成AIチャットを立ち上げて以来、3年以上にわたって生成AIの活用推進を続けてきました。最近ではKTC/KINTOで培った技術力を、トヨタグループの各社へとアドバイジングや開発支援を通じた提供もしています。 その立場から国内の状況を眺めると、対照的な数字があります。生成AIを「導入済み」と回答した国内企業は57.7%^[ NRI「IT活用実態調査(2025年)」 ]。導入の壁は、もうほとんど越えられています。一方で、AIが利益(EBIT)に5%以上効いていて、かつ大きな価値を生んでいると答えられる企業は6%^[ McKinsey "The State of AI in 2025" ]。導入はしたが、成果を出していると言い切れる会社はまだ一握りです。 おそらくこの記事を読んでいるような、新しい技術への感度が高い方は、すでに仕事が大きく変わっているはずです。メールの下書き、議事録の要約、コーディング支援。少なくとも、これらを全てカタカタ手で打っている人は、かなり減っているのではないでしょうか。しかし問題はその先です。あなたの「周りの人」はどうでしょうか。個人としては価値が出ている。でも、組織としてはどうでしょう。今回のテーマは、個人の成果と組織の成果の間にある、この溝についてです。 2. キャズムのどこに手を打つか ― 今日は「B」の話 本題に入る前に、組織へ新しいものを広げるときのイメージを共有させてください。何度も見たであろう、キャズム理論^[ジェフリー・ムーアが提唱した、新技術の普及プロセスを説明する理論。利用者をイノベーター/アーリーアダプター/アーリーマジョリティなどの層に分け、層の間にある溝(キャズム)を越えることの難しさを論じたものです。]の図です。 新しい技術や文化を組織へ広げるときの手法。A・B・Cのどこに手を打つか これは生成AIの話だから持ち出した図ではありません。DXのときも、RPAのときも、新しい技術や文化を大きな組織に入れる場面では、いつもこの概念を使ってきました。 図にはA・B・Cという3つの矢印を描いています。それぞれが別の打ち手です。みなさんの組織は、いまどの矢印に手を打っているでしょうか。そしてご自身はどの層にいて、どの矢印ならコミットできそうでしょうか。そんなことを考えながら見てもらえればと思います。 A:イノベーターに自由を渡す。 新しいものは、放っておいても勝手に調べ、勝手に始め、勝手に実験してしまう人たちがいます。彼らにできる限り自由な環境を渡す。ただ自由なだけでなく、ガードレールを敷いて「ここでなら安心して遊んでいい」という空間にするのがAです。 B:キャズムに橋をかける。 イノベーターやアーリーアダプターが見つけた価値に、アーリーマジョリティ以降の人たちが追従できるよう、崖になっているキャズムへ橋をかける取り組みです。 C:後ろ向きな層を動かす。 配ってもなかなか触ってくれない、興味を持ってもらいにくい層に、どう使ってもらうか。ここに悩んでいる会社さんは、きっと多いはずです。 今日お話しするのは、このうちBが中心です。Bをやるには、その手前でAも回っている必要があるのですが、本記事では「見つかった価値を、キャズムの向こう側へどう渡すか」に軸足を置きます。 3. 価値創出の両輪 ― 探索と実装 組織で価値を出すには、2つの循環が要る、と私は考えています。 1つは探索。イノベーターやアーリーアダプターにあたる人たちが自由に価値を探せる環境を用意し、「この使い方は効く」という発見を生んでもらうフェーズです。もう1つは実装。見つかった0→1の発見を、組織に固定して10にも100にもするフェーズです。藪まみれの中をしらみつぶしに歩いてゴールを見つけるのが探索だとすれば、見つかった道を舗装して誰でも歩けるようにするのが実装です。 探索だけでは、個人の発見で止まります。IRレポートに載るようなインパクトは、個人技からは出ません。逆に、発見のない組織でいきなり実装(仕組み化)から入ると、舗装すべき道がどこにあるのか分からないまま工事が始まります。これらは両輪であってどちらが欠けても前進することはできません。 ここからは、KTCがこの両輪をどう回しているか、探索→実装の順でお話しします。 4. 探索:トークンマキシング ― 自転車の乗り方は、本では学べない 探索の打ち手の一つとして「トークンマキシング(Tokenmaxxing)」^[あるものを極限まで盛るというネットスラング "-maxxing" を、トークン消費にくっつけた言葉です。]を紹介します。社内のAIのトークン消費を、とにかく最大化する。価値創出はいったん脇に置いて、まず使う量を増やす施策群のことです。 なぜ価値創出にこだわると言っておきながら、消費量に注目するのでしょう。生成AIの正しい使い方は、机上で学べないからです。私はよく自転車の乗り方に例えるのですが、自転車の乗り方を本で学んだ人は、おそらくいません。補助輪をつけて、サポーターをつけて、河原で何度も転んで、身体で覚えたはずです。「AIにこう頼むとうまくいく」「これはAIには苦手だ」という感覚も同じで、試行錯誤からしか生まれません。だから、まずたくさん漕いで、たくさん転ぶことで、AIと効率よく協業する感覚が磨かれます。 トークンマキシングを構成する施策は、「消費を増やす施策」と「消費量を観測する施策」で構成されます。 消費を増やす施策の例としては「手作業コーディング禁止」があります。一定期間、人手でのコーディングを禁止して実装はAIエージェントに任せ、人間は指示と検証に集中する、というものです。コーディング界隈で広まった施策ですが、「手作業での資料作成禁止」のように事務系へのアレンジも利きます。 私自身は資料作成へのこだわりが強く、今でもつい手作業で熱中してしまう時があるのですが、最初の1割は人間が作り、そこから7〜8割まではAIに持っていかせて、最後にまた、人間のこだわりを入れるようにしています。何度も失敗しながら最近ようやくちょうど良いAIとの協業感覚を掴めてきています。 KINTOテクノロジーズで実施した手作業コーディングを禁止する施策「Vibe Coding Week」については、Findyさんによるインタビューブログでも取り上げていただきました。 https://jp.findy-team.io/blog/ai-casestudy/kintotechnologies_vibecodingweek/ もう1つの要素が観測です。増やしっぱなしではコストが爆発するので、誰が・どれだけ使っているかを可視化する。この文脈で有名になったのがMetaの「Claudeonomics」で、8.5万人超の従業員がトークン消費量でランク付けされ、上位250名にはRPG風の称号が与えられていたそうです^[ Fortune「A Meta employee created a dashboard so coworkers can compete to be the company's No. 1 AI token user」(2026/04/09) ]。KTCでも、Claude Codeのメトリクスを各ユーザーから収集し、個人と組織それぞれの使い方を分析する仕組みを動かしています。ツールは配ったけれどその後を見ていない、という組織は、まずここから始めるのを勧めます。 KTCで運用しているClaude Codeメトリクスのダッシュボード(数値はダミーデータ) 5. ただし、トークン消費はハック可能 ・・・ただしトークン消費量は、あくまで間接指標です。 たくさん使った≠価値が出た。実際、Metaの番付では、順位のためにAIを空回しして消費量を水増しする従業員が現れたという情報もあります。そりゃそうですよね。指標は必ずハックされます。入力量で成果を測るのは、印刷したページ数で文章の質を測るようなものなので、報酬や人事評価に直接ひもづけるのは慎重であるべきです。トークンマキシングは、短期的に組織のモメンタムを作る旗印としては効きますが、ずっと続けるものではありません。習熟が進んで消費が落ち着いてくるところまでがセットです。 消費量はあくまで間接指標。指標は必ずハックされる そしてもう1つ、この打ち手には賞味期限があります。これまでのコーディングエージェントの多くは月額定額、いわば携帯のパケ放題のような契約でした。「とにかく使え」が安心して言えたのは、この建て付けがあったからです。ところが課金体系は従量制へ動いています。 GitHub Copilotは2026年6月1日から使用量ベースの課金へ移行します し、他のエージェントも続々と後を追っています。 Uberが2026年のAI予算をわずか4か月で使い果たし、コーディングエージェントの利用に従業員一人当たりの月額上限を設けた という報道も出始めました。 従量課金の世界で大事になるのは、トークンマネジメントや最適化、つまり妥当なコストで成果を増やす考え方です。難しいのは、マキシングを経験しないまま従量課金に入ってしまった組織で、転んだことのないまま管理から始めることになります。もしいま手元に使い放題のプランがあるなら、それは最後のモラトリアムかもしれません。プランが生きているうちに、探索をやり切ることをお勧めします。 定額制(パケ放題)から従量課金へ。「とにかく使え」が言えた時代は終わりつつある ここまでが探索の話。次は、見つけた発見をどう組織に固定するかです。 6. 実装:発見をAgent Skillに固める ― 発見した本人に、文書化まで背負わせない どの組織にも、キャズムでいうイノベーターやアーリーアダプターにあたる人たちがいます。新しいものを勝手に調べ、勝手に試し、「この頼み方ならうまくいく」という良い使い方を見つけてくる人たちです。問題は、その発見が本人の中にしかないことです。 そこでKTCで今増えているのが、 Agent Skill です。Agent Skillとは、AIエージェントに特定タスクの「やり方」を教える再利用可能な手順書のことで、いつ何をするかを書いた指示書(SKILL.md)、手順とOK/NGの線引き、テンプレートやスクリプトといった参照ファイルを1つのパッケージにまとめたものです。属人的だったカンコツを取り出して、誰でも再現できる形に固める。暗黙知やワザを、Skillという形で全員に配ることができます。 Agent Skillは指示書・手順/判断基準・参照ファイルの3点セット KTCの例でいうと、トヨタグループには「物と情報の流れ図(物情)」という業務の可視化手法があるのですが、このドラフトをAIに作らせるSkillを固めて、社内に配布しています。先行する人たちの発見を、お湯を注げば誰でも食べられるインスタント食品に加工して配る、というイメージです。 一方でこうした探索の担い手は、新しい使い方を探すこと自体は好きでも、それを手順書に書き起こすことには関心が薄かったりします。であれば、横串の推進組織が本人のところへ出向いて、「文書化はうちらが代わりにやります」と引き受けてしまうのはどうでしょうか。発見した本人に、文書化の手間まで負わせる必要はないかもしれません。 7. 運用と文化 ― 「手でプロンプトを打たない」という逆説 Skillは作っておしまいではなく、運用が必要です。誰でもSkillを探して使える場所(Plugin Market)を作る。命名ルールを決める・・・検索できないSkillは、存在しないのと同じだからです。ブランチ名や関数名に払っている気遣いを思い出してください。あれと同じ気遣いがSkillにも必要です。ただ、Skillの命名規則のベストプラクティスはまだ世の中に整備されていないので、会社ごとに独自で決めてしまうのが有効だと思います。それから、定期的なメンテナンス。数か月で前提が変わる領域なので、古いSkillは放置すれば負債になります。 Skill運用を支える4つの仕組み(Plugin Market・命名ルール・定期メンテ・対象発掘) そして、そのメンテナンスをどう回すか。ここが地味に大変なところなのですが、KTCではSkillの保守そのものをSkillにしてしまうことを試しています。いわば、Skillを点検・整備するためのSkill群です^[公開されているmizchiさんの「 waxa 」を参考にしています。]。役割を分けた、4つのモードがあります。 検証する:書いたばかりのSkillを、まっさらな別セッションに白紙で読ませ、「ここが伝わらない」という曖昧さや暗黙知を炙り出す。 棚卸しする:Skill群ぜんぶを複数の観点で健康診断し、どれから手を入れるべきかのリストを作る。迷ったら、まずここから。 命名を整える:名前とdescriptionだけを命名規則に合わせて直す。何をするSkillか一目で理解でき、検索で見つかる状態を保つための整備になる。 本文を直す:古いSkill名やモデル名、URLといった陳腐化した参照を、機械的に一括置換する。 コツは、各修正のポリシーきっちり分けて、1つのセッションに何もかもやらせないこと。さきほど「検索できないSkillは存在しないのと同じ」と書きましたが、その状態を保つ作業自体を、人間の根性ではなくSkillに肩代わりさせるわけです。運用とは、こういう地味な仕組みの積み重ねなのだと思います。 Skillの保守そのものをSkillにする。役割を分けた4モードで運用を回す(参考: mizchiさんのwaxa) 文化の面では、事例共有会や勉強会といった地道な取り組みを続けてください。「こんな効くSkill作ったぜ」を見せ合う場は、評価制度ではなく、つい誰かに見せたくなる気持ちで回り始めます。地味ですが、文化醸成はこういう積み重ねでしか進まないと思っています。 最後に1つ、逆説的な話を。個人の仕事を組織の仕事にする上で、プロンプトエンジニアリングのスキルが邪魔をすることがあります。個人が勘とコツでプロンプトを丁寧に調整し、エージェントをいい感じに動かすのは、良いようでいて横展開が非常にしにくい。プロンプト頼みの業務は、それ自体が属人化です。なのでKTCでは最近、組織の仕事にする場合は手でプロンプトを打つのをできるだけやめて、スラッシュコマンドやSkillの呼び出しだけで完結させることを推奨しています。上手に打てる人ほど、打たない。妙な話ですが、組織化とはそういうことだと考えています。 なお、ここまでの打ち手は、KTCがクラウド・AI領域で新しいことに踏み込みやすい立場にある、という前提と切り離せません。新しいことを試し、うまくいったものを少しずつ周囲へ広げていく——そんな意識で取り組んでいるので、キャズムでいう上位層に意識的に時間を寄せています。どの層にどれだけ時間をかけるかのポートフォリオは、自社の立ち位置や方針に従って決め、経営層と握っておくのが筋だと思います。 8. まとめ ― 個人の発見を、組織の知恵に 「個人の発見を、組織の知恵に」今回お伝えしたかったのは、結局この一行です。探索のフェーズでは、トークンマキシングでたくさん試して、転ぶことを恐れない。正しい使い方は、試行錯誤からしか生まれないからです。実装のフェーズでは、発見をAgent Skillのような形に固め、誰でも再現できるようにして配る。そして、仕組みと文化で回し続ける。 探索→実装→仕組み・文化。個人の発見を、組織の知恵に G検定やE資格を持っているような方は、すでに一本のスペシャリティがある状態です。AIは自力にレバレッジをかける道具なので、自力が10の人と100の人では、掛けた後の差がまるで違います。ご自身のドメイン知識と、資格を通じて学んだ知識と、生成AIやAIエージェントを掛け算して、まずはたくさん転ぶところから。そして、転んで見つけた発見を、ぜひ組織に配ってください。 ここまで読んでいただき、ありがとうございました! あなたや周囲の人の発見が、組織の知恵になっていくことを願っています。

こんにちは。Engineering Officeのアクセシビリティアドボケート、辻勝利です。 6月のある朝、私は名古屋のあるビルの一室で、植木鉢を両手で抱え、聞こえてくる水の音を頼りに歩いていました。隣では竹中さんが猫の鳴き声を追いかけ、浜谷さんは焼き網の上で肉が焼ける音に、息を詰めて耳をすませています。三人が手にしていたのは、どれも映像のない、「音」だけで遊ぶゲームでした。 傍から見たら、なかなか不思議な大人三人組だったと思います。でもその場にいた私たちは、ただただ夢中でした。目で何かを確かめるのではなく、耳をすませて、音だけを頼りに遊ぶ。その新鮮さに、すっかり夢中になっていたのです。 私たちが訪れていたのは、「オーディオゲームセンター」という展示でした。映像ではなく「音」からゲームをつくり、音だけで遊ぶ——そんなユニークな作品が集まった場所です。名古屋で開かれていることを知り、出張のついでに同僚を誘って足を運んでみました。 制限時間内に、音だけを頼りに花へ水をあげる「はなちゃんを救え」。会場で最初に夢中になった作品です。 この記事では、その朝のことを書いてみたいと思います。 なぜ、この三人で行こうと思ったのか 少しだけ、前日の話をさせてください。私と竹中さんは名古屋で仕事があり、前日から出張していました。 せっかく名古屋まで足を運ぶのだから、この出張をアクセシビリティの活動にもつなげられないか——そう考えていたときに、ちょうどオーディオゲームセンターの展示が名古屋で開かれていることを知りました。アクセシビリティのアドボケートとして、これはぜひこの耳で確かめておきたい展示です。そう考えた私は、竹中さんに加えて、名古屋オフィスで働く浜谷さんにも声をかけました。浜谷さんは、ドライバーに向けたサウンド設計を仕事にされている方です。「音」を扱うプロと一緒に、音のゲームを体験できる。これ以上ない組み合わせだと思いました。 正直に打ち明けると、この「お誘い」には、私なりの小さな狙いもありました。 アクセシビリティのアドボケートとして、私が会社のなかで担いたい役割は、製品やサービスを使いやすくすることだけではありません。その手前にある、「アクセシビリティの文化」そのものを社内に少しずつ根づかせていくことだと考えています。 そのためには、ガイドラインやチェックリストと向き合う時間だけでなく、まだ見たこと・触れたことのない領域のアクセシビリティに、同僚たちが自然と出会えるきっかけをつくりたい。そんな思いが、以前からずっとありました。今回の展示は、そのきっかけにぴったりだと感じたのです。 「音」を共通言語にして遊んだ、あの日の記憶 この場所に同僚を連れて行きたかった理由は、もうひとつあります。それは、私自身の忘れられない原体験です。 ずいぶん前のことになりますが、私はかつて東京で、「オーディオゲームをつくるハッカソン」に参加したことがありました。視覚障害のある人も、目の見える人も、一緒になって音だけのゲームをつくり、その場で遊ぶ。そんなイベントでした。 そこで私が感じたのは、なんとも言えない心地よさでした。その場には、難しい「アクセシビリティ」の話は、ほとんど出てこなかったのです。「視覚障害者のために」とか「配慮しなければ」といった肩に力の入った言葉ではなく、ただ純粋に、「音を中心にしたゲームって面白いよね」という一点で人が集まっていました。 「音」という共通言語の前では、目が見えるかどうかは、その場の主役ではありませんでした。みんなが同じように耳をすませ、同じように戸惑い、同じように笑う。あの対等でフラットな空気が、私にはとても新鮮で、心地よかったのです。 この感覚を、ぜひ同僚にも味わってほしい。難しい理屈ではなく、まず「面白い」から入ってもらえる体験として——そう思ったことが、今回のお誘いの根っこにありました。 当日、私たちを夢中にさせた作品たち さて、当日の会場には、いくつもの作品が展示されていました。どれも、思わず「お、これは!」と声が出てしまうような、ユニークなものばかりです。 1つめは、 植木鉢を抱えて、音を頼りに水を探すゲーム 。鉢を持って歩き回り、聞こえてくる音を手がかりに、水のありかを探し当てます。制限時間内に花へ十分なお水をあげられるかは、私たちの耳と方向感覚にかかっています。冒頭で私が抱えていたのが、この鉢でした。 2つめは、 音だけで進行する人狼ゲーム 。誰が人狼なのか、表情ではなく声と音だけで推理していく緊張感がありました。それぞれのプレーヤーには、小さなスピーカーを通して別々の振動が伝えられ、どんな振動が届いたのかを話し合いながら、誰が人狼なのかを推理していきます。自分に届いた振動のリズムを、そのまま声に出してしまわないよう気をつけながら、慎重に人狼を探しました。 声と音だけで人狼を推理する「サウンドウルフ」と、鳴き声から動物を当てるクイズ。プレーヤーには小さなスピーカーから別々の振動が届きます。 3つめは、 猫の鳴き声を頼りに、迷路の中で猫を探して捕まえるゲーム 。「ニャー」という声を追いかけて夢中になっている竹中さんの様子が、その声の弾み方から伝わってきて、なんとも微笑ましく感じました。見つけたと思った猫が、ふっと別の方向へ鳴きながら逃げていく。その手応えのなさに、私は昔飼っていたやんちゃな犬のことを思い出しました。 「Echolocation Maze ― 迷路でねこ探し」。アルミのフレームの中に入り、耳をすませて猫を探しているところ。目ではなく、音に集中する時間です。 4つめは、 音を頼りに、ちょうどよい焼き加減を狙って焼肉を焼くゲーム 。お肉が焼ける音の変化だけで、食べごろを見極める。サウンド設計を仕事にしている浜谷さんが、ここでいちばん真剣になっているのが、その張りつめた集中ぶりから伝わってきました。三人で同時にお肉を取り出すとボーナス点がもらえることもあって、それぞれが真剣にタイミングを見計らいながらゲームを進めました。 お肉が焼ける音の変化だけで、食べごろを見極める焼肉ゲーム。サウンド設計が本職の浜谷さんが、いちばん真剣に聞き入っていました。 そしてもうひとつ、ゲームというより、 動かすと振動に合わせて笑い出す提灯のおもちゃ もありました。手のなかで震えながら笑う提灯に、思わずこちらまで笑ってしまいました。子どもの頃に遊んだ「笑い袋」を思い出すような、ちょっと懐かしい作品です。 どの作品も、目で見て楽しむものではありません。耳をすませ、手で感じ、音の変化に身をゆだねて遊ぶ。気がつけば三人とも、すっかり童心に返って盛り上がっていました。 「面白い」が、いちばん最初にあっていい 会場を出たあと、私はふと、あの東京のハッカソンで感じた心地よさが、そのままここにもあったことに気づきました。 この朝、私たちは一度も、肩肘張った「アクセシビリティ」の話をしませんでした。ただ、音のゲームが面白くて、三人で笑い合っていただけです。目が見える二人と、見えない私とが、まったく同じスタートラインで戸惑い、同じように夢中になれる。そういう体験を、言葉ではなく、身体で分かち合えたことが、私にはとても嬉しかったのです。 アクセシビリティというテーマは、ともすると「正しさ」や「やらなければいけないこと」として語られがちです。それももちろん大切なことです。でも、その入り口に、こんなふうに「ただ純粋に面白い」という体験があってもいいはずだと、あらためて思いました。難しい話の前に、まず一緒に楽しんでしまう。そこから自然と、「音だけでこんなに遊べるんだ」「目に頼らない世界にも、こんな豊かさがあるんだ」という気づきが生まれていく。 これからも私は、社内のいろんな人と、こういう「触れるきっかけ」を少しずつ増やしていきたいと思っています。難しい顔で身構える前に、まず一緒に耳をすませて、笑ってしまう。アクセシビリティの文化は、案外そういう楽しい時間の積み重ねから根づいていくのかもしれない——名古屋出張の締めくくりに、そんなことを思ったのでした。 もうひとつの出会い ― 鼓動を伝えるモビリティ「QUENELLE」 会場には、オーディオゲームとは別に、もうひとつ強く印象に残った展示がありました。「QUENELLE（くねる）」という、小型EVのコンセプト作品です。 これは、乗る人の鼓動を読み取り、それを音や光、振動として映し出す乗り物でした。乗り物を「操作する道具」としてではなく、感覚でつながる相手のように感じさせてくれる——そんな試みです。私も実際にまたがらせてもらいました。 「QUENELLE」にまたがらせてもらいました。なお、同席されたスタッフの方など、ご本人の同意を確認できていない方のお顔は画像処理をしています。 鼓動を音・光・振動で映し出す、小型EVのコンセプト作品。乗り物を「操作する道具」から「ともにある存在」へと近づけようとする試みです。 ドライバーに向けたサウンド設計を仕事にする浜谷さんが、この作品の前で何を感じていたのか。それは、次の感想に譲りたいと思います。 一緒に行った二人から 最後に、同行してくれた二人に、当日の感想を一言ずつ書いてもらいました。 現地に行くまでは「音のゲーム」というものがまったく想像できず、どちらかといえば、見た目には地味で質素な作品をイメージしていました。でも、実際にプレーしてみると、自分自身が夢中になって遊んでしまうほど面白くて驚きました。子どもから大人まで、幅広い世代の人たちが一緒に楽しめる——オーディオゲームには、そんな可能性があると感じました。（竹中） 車を運転中のドライバーは、とても不自由です。ずっと前を見ていないといけないし、好きに動くこともできない。ほとんど唯一の愉しみは「音」ですが、音楽を流すか、ラジオを聴くか、同乗者とのお喋りか。それって数十年前からほとんど何も変わっていない。「音を愉しむ」って、もっと自由で、色んな可能性があるんじゃないか?と、ずっと考えていました。一緒に体験したオーディオゲームセンターの作品は、自分の中にあった漠然とした仮説を、確信へと一歩近づけてくれました。（浜谷） 目を使わずに「音」だけで遊ぶ時間は、私にとって、アクセシビリティの新しい入り口を確かめ直す時間でもありました。もし機会があれば、ぜひ一度、耳だけを頼りに遊んでみてください。きっと、思っているよりずっと豊かな世界が広がっています。 参考リンク オーディオゲームセンター: https://artscape.jp/exhibitions/64694/ オーディオゲームをつくるハッカソン（CCBT）: https://ccbt.rekibun.or.jp/events/audiogamecenter_ccbt_hackathon

はじめに QEグループでモバイルチームに所属しているmです。 前職までは約7年ほどモバイルアプリの開発をメインに従事していました。 今はQAとしてプロダクト開発に関わっています。 この記事では、QAが設計や実装といった開発側との共通言語を持っておくと、テスト設計でも不具合対応でも有効である、という話を書きます。 共通言語があると問題の切り分けがしやすくなり、開発とのコミュニケーションコストも下がるため、本来集中すべき業務に工数を割きやすくなると考えています。 なお現在も対応中の取り組みなので、効果については「こう感じている」という話も含みます。 課題：内部の変更は、影響範囲が外から見えづらい まず、この記事の出発点となる課題から整理します。 内部実装だけが変わる対応、特にユーザーから見える動作は変えないリファクタリングなどは、影響範囲が外から見えづらいという特徴があります。 例えば、Swift6対応やKMP対応、UIライブラリの移行などが該当するかと思います。 挙動レベルの影響は開発から共有されるものの、外から触っているだけではどこがどう変わったのかを把握しにくいです。 そのため、テスト設計では「影響範囲が分からないので、念のため全項目をテストしよう」となりやすく、 不具合対応では「ゼロから原因を探そう」という方向に傾きやすくなります。 ただ、実際には期日などの制約もあるため、すべてを見るわけにもいかない場合があります。 この「影響範囲が外から見えづらい」という点が、このあと述べる2つの工程（テスト設計と不具合対応）に共通する課題になります。 前提：アプリ側の設計・実装を把握して見る 課題への向き合い方として、まず普段行っている見方を記載します。 アプリは一枚岩ではなく、機能や役割ごとに分かれて作られています。 たとえば、画面の見た目を作る部分、データを加工する部分、サーバーと通信する部分、データを保存する部分、といった具合です。 何かが起きたとき、「画面上どう見えるか」だけで捉えるのではなく、 「それはどの責務の話なのか」「どことつながっているのか」を、アプリの作りの上で考えるようにしています。 これが、本記事で言う「構造から見る」という見方です。 たとえば「ログイン後の表示がたまにおかしい」という事象であれば、見た目を作る部分ではなく、 データを取得する通信や処理の部分が怪しいのではないか、と当たりをつける、といった具合です。 もちろん開発経験があるため、コードや設計資料を見れば、どの部分がどのように動き、どこにつながっているかは比較的把握しやすいほうだと思います。 ただ、この見方だけに頼るのではなく、開発側にも影響範囲の資料を展開していただいています。 そして、この見方がまず効くのが、テスト設計です。 テスト設計：見るべき範囲を、根拠を持って絞る 先ほどの「つい全項目をテストしたくなる」場面を、前項の考え方で設計します。 ここで行うのは、実装を隅々まで読むことではありません。「この変更は何をしようとしているのか」「だとすれば、何が壊れそうか」を、設計レベルで把握することです。 ここが分かると、何を見るか・どこまで見るかの手がかりになります。 具体的には、次の3つを問いとして使っています。 ①動作は変わるのか、変えないはずなのか 変えないはずの変更であれば、見るべき軸は「変更前と同じか（同等性）」になります。見た目や操作感が、変更前と変わっていないかを確認する、ということです。 ②技術的にどこへ影響のある変更なのか 並行処理なのか、UIの作りなのか、通信まわりなのか。 影響する領域が分かると、その領域で起きやすい問題が、見るべき観点になります。 たとえば並行処理が変わるのであれば、断続的に固まる・クラッシュする・反映が遅延する、といった点です。 ③どの単位で入る変更なのか 画面単位なのか、モジュール単位なのか。これが分かると、見る範囲の単位が定まります。 たとえば、今回改修した画面のみを対象にする、といった具合です。 この3つの問いで根拠を持って絞れると、見る範囲が現実的なところに収まります。 「全部やる」から「変更によって壊れそうな箇所を確かめる」へ変わる、という感覚です。 あわせて、開発との「どこまで実施するか」のすり合わせも速くなると考えます。 後工程でも効く：不具合の起票と切り分け ここまではテスト設計の話でしたが、メリットはその先の工程にも続くと考えています。 テスト設計の段階で把握した「この変更はどの実装箇所に影響があるか」という理解は、不具合の起票や切り分けの場面でも、そのまま活用できます。 一度読み込んだ作りが、ここでも改めて効いてくる、という形です。 そのため、案件にもよりますが、起票を見た時点で「このあたりが怪しいのではないか」と当たりをつけ、仮説つきで起票できます。 たとえば、表示崩れ・断続的に固まる、iOS・Android共通の不具合、といった切り口で、どの部分の話なのかを見立てられます。 重要なのは、これは「QAが原因を完璧に特定できる」という話ではない、ということです。 あくまで当たりをつけ、仮説を立てるところまでです。ただ、その仮説があるかないかで、その後の動きはかなり変わると考えています。 「画面が固まりました」とだけ書かれた起票と、 「ここは非同期処理の変更が入った画面なので、そのあたりが怪しいかもしれません」という仮説つきの起票とでは、 開発側が状況を把握する速さも、誰に依頼すべきかの的確さも変わってきます。 切り分けが、「ゼロから探す」から「仮説を検証する」へ変化し、開発とQA双方にとってメリットが生まれるかと思います。 実装に寄りすぎない ひとつ、意識していることがあります。 現在の実装に寄りすぎると、「すでに実装されているもの」をなぞるだけになり、本来あるべきなのに、実装として抜けている観点を見落とすおそれがあります。 そのため、開発から共有された「本来こう動くべき」という挙動レベルの情報と、 コードや資料から読み取った「現状こうなっている」という状態を、突き合わせるようにしています。 構造理解で当たりをつけつつ、「ユーザーから見てどうあるべきか」という挙動ベースの視点も手放さない。 このバランスが大事だと考えます。 まとめ 今回の内容を要約すると、こうなります。 構造を理解しておくと、テスト設計でも後工程でも、QAの動きが「探す」から「検証する」へ変わる。一度の歩み寄りが、複数の工程で効いてくる。 もちろん、自身の背景などから知見があったという側面はありますが、それがないと無理な話ではないと考えています。 まずはプロジェクトのアーキテクチャ図や設計資料を読んでみる、詳細設計の境界を意識してみる、変更がどの設計箇所に影響するのかを開発に聞いてみる。 そうした小さなところからでも、見立ては変わってくるかと思います。 内部実装の変更で「全部見るしかない」となりがちな場面でも、構造から攻めることで、影響範囲の見立ての精度を上げられます。 同じような場面に立っている方の参考になれば嬉しいです。

0. はじめに 弊社では Claude Code を全社的に導入しており、Claude Code のメトリクスとログを OpenTelemetry で収集し、Grafana で可視化しています。ところがある日、こんな声が飛んできました。 「ダッシュボード、また固まってるんだけど」 社内に Claude Code を展開して、いざ「みんなどれくらい使ってる？」を可視化しようとしたら、開いたダッシュボードがくるくる回り続けて何も出てこない。タイムアウト。リロードしてもまた回る。 原因は Claude Code が吐く 1 つのメトリクス claude_code_token_usage_tokens_total でした。これがカーディナリティ爆発（カーディナリティについては後述）を起こして、Thanos Query のメモリで使い倒していました。 この記事は、その障害を Grafana Managed Recording Rule × Prometheus × Thanos の構成でどう捌いたか、の記録です。打ち手を 3 案で比較した話と、採用案で実際にハマった「書き込み先（write 先）問題」を 2 段階でほどいた話がメインです。同じように AI ツールの利用状況を可視化したい人、そして高カーディナリティに殴られた経験のある Observability 担当者の参考になればと思います。 :::message この記事の構成は「検証で動作確認し、現在は短縮稼働で運用している」段階のものです。本番フル稼働の数値ではなく、構成判断のプロセスと再現できる設計を中心にまとめています。 ::: 1. 何が起きていたか：claude_code_token_usage_tokens_total のカーディナリティ爆発 Claude Code は OpenTelemetry 経由でトークン使用量などのメトリクスを出力できます。その中心が claude_code_token_usage_tokens_total です。 問題はラベルでした。このメトリクスには session_id が付きます。セッションごとにユニークな ID が振られるので、 利用が増えれば増えるほど系列（time series）が線形に増え続ける 。さらに user_email 、 model 、 type （input/output/cacheRead など）も掛け算で効いてくる。 claude_code_token_usage_tokens_total{ session_id="...", # ← セッションごとにユニーク。爆発の主犯 user_email="...", model="claude-...", type="output" } :::details カーディナリティとは メトリクスにおけるカーディナリティとは、あるラベルが取りうる値の種類数のことです。たとえば type ラベルの値が input ・ output ・ cacheRead の 3 種類しか振られなければカーディナリティは低い。一方 session_id のようにセッションごとに異なる値が振られるラベルは、セッションが増えるほど無限に種類が増えていく「高カーディナリティ」なラベルです。ラベルの組み合わせが時系列（time series）の数になるため、高カーディナリティなラベルが 1 つあるだけで系列数が爆発的に膨れ上がります。 ::: session_id のような無限に増える値（unbounded label）が 1 つ混じるだけで、系列数は天井知らずになります。 そして Thanos Query は、クエリ時に対象系列を メモリ上に展開してから 集計します。系列が数十万を超えてくると、 sum by (user_email) のような一見シンプルな集計でもメモリを食い尽くし、タイムアウトか OOM で落ちる。ダッシュボードが固まっていた正体はこれでした。 2. KTC のモニタリング基盤の構成 本題に入る前に、今回の話に登場するコンポーネントを整理します。 2-1. Alloy（OpenTelemetry Collector） Grafana Alloy は OpenTelemetry ベースのコレクターです。KTC では各システムの AWS サービスのログやClaude Code からメトリクス・ログを収集する入口として機能しています。 2-2. Prometheus Kubernetes 上のメトリクスを scrape する OSS の監視ツールです。KTC では scrape したメトリクスを Thanos Receiver への remote write で転送するリレー役を担っています。メトリクスの長期保存は Thanos に委ねる構成です。 2-3. Thanos Prometheus をスケールアウト・長期保存対応させるための OSS です。KTC では以下のコンポーネントで構成しています。 コンポーネント 役割 Routing Receiver remote write の受口。hashring に従って Ingesting Receiver へルーティング Ingesting Receiver 実際の TSDB への書き込み。S3 へ flush Store Gateway S3 のブロックをクエリ可能にする読み取りゲートウェイ Query 実際にクエリーを実行するコンポーネント。 Query Frontend クエリのキャッシュ・スプリットを担当。Grafana からの入口 Compactor S3 のブロックを定期的に圧縮・ダウンサンプリング マルチテナント構成を採用しており、書き込み時は通常 THANOS-TENANT HTTP ヘッダーでテナントを指定します。 2-4. Grafana Grafana は Thanos をデータソースとして接続し、ダッシュボードの描画と Recording Rule の管理を担います。KTC ではシステム単位でマルチテナント化した Grafana インスタンスを各チームに払い出しており、今回 Claude Code コスト可視化用に専用インスタンスを立ち上げました。 3. 課題とゴール 「じゃあ session_id を消せば終わりでは？」と思いますよね。でもそれが簡単に言えない理由がありました。 社内で AI 活用を進めるには、まず 測れること が前提になります。誰がどれくらい使っているのか、どのモデルにトークンが寄っているのか、1 セッションあたりの規模感はどうか。こういう粒度がないと「活用が進んでいるのか」を語れない。 特に session_id 単位の分析は、後から「効果的な使い方をしているチームの傾向を見たい」みたいな分析に効いてきます。つまり 生データとしての session_id は手元に残したい 。でも ダッシュボードのクエリでそのまま頑張るのは無理 。この二つを両立させるのが今回のお題でした。 ゴールはこう整理できます。 生データ（ session_id 付き）は Thanos に貯め続ける ダッシュボードは「集約済みの軽いメトリクス」を見る 利用者がセルフサービスで見たい情報を見れるように調整ができること 4. 案比較 カーディナリティへの対象策はいくつかあります。今回は 3 案を並べて比較しました。 案 やること メリット 採用/不採用の理由 案1: Alloy でラベルドロップ 収集段階で session_id を捨てる 一番手前で止められて確実 生データから session_id が消え、後の分析が永久にできなくなるため、今回は不採用 案2: Thanos Ruler サーバ側の Recording Rule で集約 集約結果が Thanos に永続化される ルールの Apply が Platform 側でのオペレーションのみになる運用を実施しているため、利用者とPlatformでのやりとりが増えて運用負荷が高いため、今回は不採用 案3: Grafana Managed Recording Rule Grafana 側で集約ルールを定義し書き戻す 利用者が UI で自分でルールを作れる 生データを残しつつ、ルールの主権を利用者に渡せるため、 今回は 採用 判断の軸は 2 つでした。 生データを失わないか （ session_id を残せるか） ルールを誰が育てられるか （利用者が回せるか） 案1 は軸1で不採用。収集段階で捨てるとデータ分析に利用できません。案2 は軸2で不採用。Thanos Ruler はサーバ側のルールファイルを Platform が管理する世界なので、「ちょっとこの集約を試したい」が毎回 Platform への依頼になってしまう。これは Platform チームのボトルネック化も招きます。 残った案3 が、両方の軸をクリアしました。 5. Remote Write 先問題を 2 段階で解いた 案3 を進める上でも課題がありました。Grafana Managed Recording Rule は「集約した結果を どこかに書き戻す 」必要があります。メトリクスの管理に使っているThanosの場合はここがうまく設定できませんでした。 5-1. 詰まり1: Datasource に Thanos Receiver を直接指定できない Thanosにおいて、メトリクスの書き込み先は Thanos Receiver であるので、 Grafana の Datasource で Thanos Receiver を指定することを考えました。 ところが Datasource として登録できませんでした。理由はこうです。 Grafana の Datasource は基本的に Query（読み取り）系 に対して作るもの Thanos Receiver は Write 専用 で、Query を受け付けられない だから Receiver は Datasource として成立しない ここで再検討した結果、既に別用途で使用していた Prometheus でした。Prometheus は Query も Write（remote write 受信）も両方できる 。そこで Prometheus を Grafana の Datasource として指定することにしました。 Grafana の Datasource → Prometheus（Query を受け付けらるので Datasource になれる） Recording Rule の書き戻し → Prometheus の /api/v1/write で受ける(※) Prometheus が remote write で Thanos Receiver へ流す という形にしました。Prometheus が「Query 窓口」と「Write の中継」を兼ねることで、Datasource 問題が解けました。 ※ Prometheusはデフォルト設定では、Queryを受け付けられないので --web.enable-remote-write-receiver フラグを有効にし、外部から /api/v1/write でメトリクスを受け付けられる** にしています。 5-2. 詰まり2: マルチテナントへの書き込み（HTTP ヘッダーを操作できない） 次の壁はマルチテナントでした。Thanos Receiver はテナントを分けて受け取れますが、その振り分けは通常 HTTP ヘッダー（ THANOS-TENANT ） で指定します。 ところが Grafana Managed Recording Rule の設定項目には、 書き戻し時の HTTP ヘッダーを差し込む設定がありません 。ルールの式と書き戻し先は指定できても、ヘッダーは触れない。AI 活用用のテナントへ正しく振り分けたいのに、その手段が塞がれている状態でした。 解決には Thanos Receiver 側の機能を使いました。 thanos receive \ --receive.split-tenant-label-name="tenant_id" --receive.split-tenant-label-name を指定すると、Receiver は HTTP ヘッダーではなくメトリクスのラベル値 を見てテナントを振り分けてくれます。つまり、 Recording Rule の集約結果に THANOS-TENANT="ai-usage" のようなラベルを付けておく Receiver がそのラベルを読んで AI 活用用のテナントへ流し込む ヘッダーが操作できないなら、振り分けの判断材料をラベルに寄せる。発想を「ヘッダーで指定する」から「ラベルで宣言する」に切り替えたのがポイントでした。 5-3. 全体アーキテクチャ 2 つの詰まりを解いた結果、データの流れはこうなりました。まず全体像を俯瞰します。 ポイントをまとめると： Prometheus が二役 ：Grafana からの write を受け取る --web.enable-remote-write-receiver と、Thanos への転送（ remote_write ）を同時に担う テナント振り分けはラベルベース ：Routing Receiver の --receive.split-tenant-label-name=THANOS-TENANT により、Recording Rule で付けた THANOS-TENANT ラベルの値でテナントが決まる。HTTP ヘッダーを操作できない制約をラベルで回避した 6. Before / After：タイムアウトが消えた 検証段階での効果はシンプルです。 観点 Before After ダッシュボード表示 タイムアウト / 描画されない 集約済みメトリクスを描画できる Thanos Query への負荷 高カーデ系列をメモリ展開して OOM 級 集約済みの軽い系列を読むだけ session_id 単位の生データ 残る 残る（Thanos に蓄積継続） 集約ルールの主権 （案2なら Platform） 利用者が UI で保持・編集 ダッシュボードが普通に開く、という当たり前を取り戻しつつ、生データも分析の主権も手放さずに済んだ、というのが今回のゴールでした。 7. まとめ 今回やったことを、次に同じ状況に出会った人が調査・検討できる粒度で残しておきます。 無限増殖するラベル（ session_id 等）はカーディナリティ爆発の主犯 。 生データを収集段階で捨てる前に「後の分析で使うか」を問う 。Alloy でのドロップは確実だが取り返しがつかない Thanos Receiver は Write 専用なので Datasource にできない 。Query も Write もできる Prometheus を中継に挟む Grafana Managed Recording Rule は書き戻し時に HTTP ヘッダーを操作できない 。テナント振り分けは --receive.split-tenant-label-name でラベルベースに寄せる ここまで読んでいただきありがとうございました！

はじめに こんにちは、KINTOテクノロジーズ（以下、KTC）のQuality Engineering グループでQAエンジニアをしているろきです。 本記事では、マインドマップを使った観点作成の導入経緯、実際の使い方、そして運用を通じて見えてきたことをお伝えします。 マインドマップを試すことになった経緯 現在、QAチームでは観点をConfluenceのページで作成しており、画面単位ではなくテストの目的別（機能確認・表示確認・バリデーションなど）にページを作成し、箇条書きやテーブルで管理しています。 テストの目的別で観点を作成すると同一画面の観点が複数ページに分散するため、全体を一覧で見渡したいと感じる場面がありました。 そこで、1つのボードでQA対象範囲全体の観点を俯瞰できるマインドマップの活用を提案し、試験的に導入することになりました。 マインドマップの作成ルールと構造 ツールを導入するにあたり、作成ルールを統一しました。 使用ツール マインドマップはMiroを使用しています。 基本構造 マインドマップは以下の階層構造で作成しています。 案件名_verX.X.X > 画面/機能 > 観点 > 因子 > 水準 > 期待値 何をマインドマップにするか 現在、KTCのQAチームでは、テスト観点を主に以下の5つに分類して作成しています。 シナリオ 機能確認 表示確認 バリデーション アドホック このうち、マインドマップ化の対象としているのは主に以下の3つです。 機能確認 表示確認 バリデーション 表示確認やバリデーションはConfluenceでリスト化して管理しているため、テスト対象ごとに「表示確認を参照」「バリデーションを参照」のように参照先を記載し、黄色のマーカーで色分けするルールにしています。こうすることで機能確認の観点との区分けがはっきりし、どの対象をどの観点で確認するかを過不足なく整理できます。 一方、 シナリオテストやアドホックテストの観点はマインドマップにしません 。 これらは、機能確認などと比べるとマインドマップで構造化して整理する必要性が低いため、従来通りConfluenceで文章形式のものを使用する運用としています。 使ってみてわかったメリット テスト対象の観点を1か所で把握できる マインドマップ導入における最大のメリットは、1つの画面/機能に関するすべてのテスト観点を1か所で把握できる点でした。 従来のドキュメント形式では観点の種類ごとにページが分かれているため、「この操作はどの観点で確認するのか」を複数ページにまたがって探す必要がありました。マインドマップでは画面/機能を起点に観点が集約されるため、作成時に「各テスト対象にどの観点が紐づいているか」をリアルタイムで確認しながら進めることができます。結果として、テスト対象物と観点の対応関係における過不足を発見し、修正しやすくなりました。 マインドマップがそのままテスト設計の「下書き」に マインドマップは観点から因子・水準へと枝を広げていく構造上、「通知ON/通知OFF」「入力あり/なし」といった条件分岐を自然に書き出せます。具体的な条件分岐まで落とし込めるため、観点とテスト設計を同時に整理できるようになりました。 条件分岐を書くことで、観点と仕様の精度が上がる 条件分岐を書き出す過程で「この条件の場合の仕様が書かれていない」と気づくケースも増えました。観点作成の段階で仕様の抜け漏れを発見できるため、開発チームやPMへの仕様に関する質問や、仕様書レビューをスムーズに進めやすくなりました。 さらに、「ログイン済み/未ログイン」のように対になる条件が枝として横並びになるため、片方だけ記載されていないケースが視覚的にわかりやすくなります。ある観点の枝だけが極端に少ない・多いといったアンバランスも視覚的に気づきやすく、観点の粒度を揃えやすくなりました。 議論が活発になり、認識合わせに有用 これは導入前には想定していなかったことですが、マインドマップを開発チームとの認識合わせの場で使うと、議論がより活発になりました。視覚的に構造が見えることで「この条件でもテストしてほしい」「この枝はカバレッジが高いので減らしてもいいのでは」といった具体的なフィードバックが出やすくなり、認識合わせに有効でした。 見えてきた課題 Confluenceとの連携 MiroボードをConfluenceに埋め込む際、現状では画面/機能単位で特定範囲だけを埋め込むことができず、ボード全体が表示されてしまいます。画面/機能ごとにピンポイントで埋め込めるようになると、Confluenceとの連携がより使いやすくなると感じています。 コスト 現在はトライアルとして数人のみ契約していますが、チーム全体での利用が本格化する場合はコストが増加します。ボードの作成/編集には契約アカウントが必要ですが、ゲストアカウントであれば閲覧やコメント追加ができるため、用途に応じて使い分けていければと思っています。 まとめ Confluenceと併用したマインドマップの導入は、テスト観点の具体化・可視化という点で大きな効果がありました。特に「観点が自然と具体的になる」「議論が活発になる」という副次効果は、設計品質向上に貢献していると感じています。 一方で、Confluence連携やコストといった課題も見えてきました。 まずは無料プランで気軽に試せるツールなので、「テスト観点の整理がうまくいかない」と感じているQAチームにはぜひ一度試していただきたいと思います。

SeleniumConf & AppiumConfとは ブラウザ自動化・モバイル自動化のコミュニティを世界中から集める国際カンファレンスです。 Software Freedom Conservancyが運営しており、SeleniumおよびAppiumのコアコントリビューターも登壇します。 Selenium 5に関する今後の展望、WebDriver BiDi、Appium、Playwright、Cypress、AIテスト、セキュリティテスト、アクセシビリティテストなど、幅広いテーマを扱っています。 基調講演・ハンズオンワークショップ・ネットワーキングの3つの形式で構成されています。 全セッションに英語字幕とスペイン語通訳が提供されるなど、グローバルな参加者を意識した運営が特徴です。 今年は 2026年5月6日〜5月8日 にスペインのバレンシア・Veles e Ventsにて開催され、20カ国以上から約350名が参加しました。 1日目はハンズオンワークショップ、2〜3日目がカンファレンス本番という構成でした。 https://seleniumconf.com/ 今回、KINTOテクノロジーズから 呂文佳 と パンヌウェイ の2名が登壇しました。世界の舞台でKINTOテクノロジーズの取り組みを発信できた、非常に貴重な機会となりました。 登壇者 発表タイトル（英語） 発表タイトル（日本語） 呂文佳 From 50% Cost Reduction to 90% Coverage: Playwright × AI for Non-Technical QA Teams コスト50%削減からカバレッジ90%へ〜Playwright × AI：コーディング経験が浅いQAチームの実践 パンヌウェイ Scaling Mobile Test Automation with Appium and AI: Real Lessons from KINTO Technologies モバイルテスト自動化のスケーリング　Appium と AI の活用 バレンシアまでの道のり CfPの告知から登壇当日まで、約8ヶ月の期間がありました。最初のきっかけは2025年9月、会社の同僚が社内SlackチャンネルでCfP（Call for Proposals）開始を告知してくれたことです。「ぜひ挑戦してみてください！」というその一言が、すべての始まりでした。 時期 マイルストーン 内容 2025年9月 CfP告知 会社の同僚がSlackチャンネルでCfP開始を告知。「ぜひ挑戦してみてください！」の一言がきっかけ 2025年10〜11月 CfP作成・社内レビュー チーム内でレビューを依頼し、発表内容と構成を確認し、ブラッシュアップ 2025年12月〜2026年2月 CfP提出・当選通知 最終タイトルを確定。SeleniumConfより提出確認メールを受信後、CfP当選の通知を受ける 2026年2〜4月 採択・スライド作成・発表練習 社内のAIファースト勉強会で日本語版の発表練習を実施。KTC室町オフィスのJCT（会議スペース）で英語版の発表練習と発音練習を2回実施 2026年5月 本番登壇 🎉 バレンシア Veles e Vents にて45分登壇 :::details 承認・ビザ手続きについて CfP当選後は社内手続きも必要でした。社長に登壇内容を説明して承認をもらい、その後カンファレンスチームとメールでやり取りしながらビザ申請の手続きを並行して進めました。国際カンファレンスへの参加には、こうした社内外の調整も大切な準備の一部です。 ::: 参加セッション一覧 日時 セッション名 登壇者 05/06 09:00〜 Making Sense of Mobile Automation with Appium and WebdriverIO to turn frustration into understanding Wim Selles, Christian Bromann 05/07 11:20〜 Quantum Automation: Rethinking Selenium & Appium in the Age of AI Baris Sarialioglu 05/07 11:20〜 From 50% Cost Reduction to 90% Coverage: Playwright × AI for Non-Technical QA Teams 呂文佳 05/07 13:20〜 Test Automation Workflows with Cursor Filip Hric 05/08 Scaling Mobile Test Automation with Appium and AI パンヌウェイ 2026/05/06（1日目）：ワークショップ 1日目はカンファレンス本番前のワークショップデーです。終日1つのセッションに集中して参加しました。 Making Sense of Mobile Automation with Appium and WebdriverIO 登壇者 Wim Selles — 2025 Tokyo Test Festにも参加した方 Christian Bromann 内容と学び このワークショップでは、Appiumを ゼロからインストールして2分以内にセットアップが完了する ことを実際に確認しました。セットアップの簡単さを体感できたことで、導入ハードルへの認識が変わりました。 ワークショップ後、登壇者のWim Sellesさんと直接Appiumについて相談する機会も得ました。特に「 要素特定にIDを使うかXPathを使うか 」という実務的なテーマについて深く議論し、それぞれのメリット・デメリットを理解することができました。 ID： 高速・安定だが、開発側でIDが付与されていない場合は使えない XPath： 柔軟性が高いが、UI変更に弱くFlaky Testの原因になりやすい :::details ディナーでの交流（1日目夜） 1日目の夜はカンファレンス関係者とのディナーがあり、非常に充実した交流の場となりました。 Kazuaki Matsuo さんと同席し、Appiumの導入経験や現場の課題について情報交換をしました。 Oscar Barrios さん（昨年も登壇された方）とは今年のイベントの印象やコミュニティの動向についてお話ししました。 Ivan del Viso さん（昨年も登壇された方）は、ご自身が開発したアプリを使った自動化テストのデモを見せてくれました。英語で1行のテストシナリオを書くだけで、実行・分析・ダッシュボードレポートの生成まですべてが完結するシステムで、非常に印象的でした。 ::: 2026/05/07（2日目）：カンファレンス本番 2日目からいよいよカンファレンス本番です。複数のトラックが並行して開催され、関心のあるセッションを選びながら参加しました。 セッション①：Quantum Automation — AI時代のSelenium & Appium Quantum Automation: Rethinking Selenium & Appium in the Age of AI （登壇者：Baris Sarialioglu） AI時代における自動化テストの在り方を問い直す内容でした。セッション中に聴衆から質問が上がった場面では、登壇者が次のように答えたのが印象に残っています。 セッション②：呂さんの発表（11:20〜40分） From 50% Cost Reduction to 90% Coverage: Playwright × AI for Non-Technical QA Teams KINTOテクノロジーズの同僚・呂文佳さんによる発表です。コーディング経験が浅いQAメンバーでもPlaywright × AIを活用することでテストカバレッジを大幅に向上させた実践事例を紹介しました。同じチームのメンバーが国際カンファレンスで発表する姿は、大きな刺激になりました。 セッション③：Test Automation Workflows with Cursor（13:20〜90分） Test Automation Workflows with Cursor 登壇者： Filip Hric Cursor（AI統合コードエディタ）を活用したテスト自動化ワークフローについて90分間フルで講演されました。ClaudeとGitHub Copilotの基本的な設定・活用方法がメインテーマで、Mobile QAで一緒に作業している岡さんに教えていただいた内容とほぼ同じでした。世界のカンファレンスでも同様のアプローチが注目されていると確認できたことは収穫でした。 この日のセッション終了後、翌日に控えた自分の発表準備のためホテルへ戻り、最終調整を行いました。 2026/05/08（3日目）：自分の発表 いよいよ自分の登壇日です。朝から会場でスライドの確認と発音練習を行いました。 発表概要 項目 内容 タイトル（英語） Scaling Mobile Test Automation with Appium and AI タイトル（日本語） モバイルテスト自動化のスケーリング　Appium と AI の活用 発表時間 40分 ＋ 質疑応答 会場 Veles e Vents（バレンシア） 参加状況 満席 なぜCfPが採択されたのか :::message 国際カンファレンスで登壇できることは非常に光栄なこと。世界中のテストエンジニアが集まる場でKINTOテクノロジーズの取り組みを発信できる貴重な機会です。 ::: 今回、採択につながったポイントは、単なる成功事例の紹介ではなく 現場で直面した課題と改善の過程を正直に共有した 点にあると考えています。 実際に直面した課題と、改善によって得られた成果を正直に共有 したこと（理想論ではなく現場の実態） 具体的な数値 で課題を提示：128件のテスト実行に12時間かかっていたという課題を可視化 Claude・Copilot・DevinAI の実践的な活用方法と3ツールの比較 聴衆が 持ち帰ってすぐに実践できるチェックリスト を提供したこと 発表構成（45分） # セクション名 内容 1 The Breaking Point 128テスト・実行12時間という限界点と、その背景にある課題 2 Framework Evolution 課題解決のためのフレームワーク再設計と進化の過程 3 AI Integration Claude・Copilot・DevinAIの統合で得られた成果と課題 4 Tools to Culture ツール導入にとどまらない「チーム文化」への変革 5 Visual Regression Test AIを活用したビジュアルリグレッションテストの実践 6 Real Impact & Takeaways 実際の改善数値と、明日から使える実践チェックリスト 当日の会場の様子と反響 20カ国以上から参加者が集まる満席の会場での登壇でした。発表後の質疑応答では予想以上に多くの質問が集まりました。 ドイツ在住のパキスタン出身のエンジニア から、Appiumの社内導入に関する具体的な質問を多数いただきました。自分たちのチームでも同様の課題を抱えており、ぜひ参考にしたいとのことでした。 複数の参加者から「 自分たちの導入方法の参考になった 」と直接声をかけていただきました。 発表がただの情報共有にとどまらず、世界中のエンジニアの実務に役立ったと感じることができ、大変嬉しかったです。 スポンサー企業との交流と自動化テストツールの調査 カンファレンスにはテスト自動化ツールのスポンサー企業がブースを設けており、担当者から直接、各ツールの詳細を聞く貴重な機会がありました。ここでは、カンファレンスの場で実際に収集した情報をもとに、4つのツールを比較・整理します。 各ツールの概要 ツール 特徴 CloudBeat テスト自動化、実行、分析、モニタリングを統合したクラウド型の品質管理プラットフォーム Sauce Labs エンタープライズ向けクラウドテストの先駆的存在。Salesforce、Twitter、Bank of America などの大手企業で採用実績がある BrowserStack 3,500以上のブラウザ/OS組み合わせ・30,000台以上の実機デバイスを持つ業界でも有数の大手 LambdaTest 2026年1月に「TestMu AI」へリブランドしAIネイティブ化。KaneAIによる自然言語からのテスト自動生成が特徴 機能比較マトリクス 評価項目 CloudBeat Sauce Labs BrowserStack LambdaTest Webテスト ◎ ◎ ◎ ◎ モバイルアプリテスト △ ◎ ◎ ◎ コードレステスト ◎ △ △ ○ 並列実行 ◎ ◎ ◎ ◎ CI/CD連携 ◎ ○ ◎ ◎ AI機能 ○ ○ ○ ◎ 実機デバイス数 少 多 最多 多 価格 中 高 高〜中 低〜中 日本語サポート △ △ ○ △ 初心者にとっての導入しやすさ ○ △ △ ○ 凡例：◎ 優秀　○ 良好　△ 要改善 各ツールの詳細印象 :::details CloudBeat 強み コードレステストが充実しており、プログラミング経験がなくてもテスト作成・実行が可能 Selenium・Appium・Cypress・Playwright等の主要フレームワークと幅広く統合 AIドリブンなテストレポートで根本原因分析（Root Cause Analysis）が容易 テスト実行・管理・モニタリングをすべて1プラットフォームで完結できる 弱み モバイルアプリテスト（ネイティブアプリ）の対応デバイス数がBrowserStackなどに比べて少ない 英語のみの対応で、日本語UIや日本語サポートが提供されていない 他ツールと比べると国内での導入事例や公開情報が少なく、長期利用を前提とする場合は追加調査が必要 ::: :::details Sauce Labs 強み 長年の実績を持つエンタープライズ向けプラットフォーム。信頼性・安定性が高い SOC2 Type II・GDPR・ISO 27001等のセキュリティ・コンプライアンス認証を取得 Webテストもモバイルアプリテストもどちらもカバーできるオールラウンダー 弱み 今回確認した条件では4ツールの中でも価格面の負担が大きく、中小チームや予算が限られた組織には慎重な検討が必要 コードレステスト機能が弱く、プログラミングスキルがないメンバーには難易度が高い 一部CI/CDツール（AWS CodePipeline・GitLab CI等）に非対応 ::: :::details BrowserStack 強み 実機デバイス数・ブラウザ組み合わせ数が 業界最多水準 （30,000台以上）で、網羅的なテストが可能 Accessibility Testing・Percy Visual Testingなど高度な付加機能が充実 カスタマーサポートの評判が良く、ドキュメントが整備されている 弱み 料金が高額で、コスト面での負担が大きい 基本的にSelenium/Appium等の自動化スクリプト記述が必要で、非エンジニアには敷居が高い ネットワーク遅延や実機テストでの偽陽性（誤検知）が報告されることがある ::: :::details LambdaTest（現 TestMu AI） 強み KaneAI により、自然言語でテストケースを記述するだけでスクリプトが自動生成される 今回比較した条件では、4ツールの中でもコストパフォーマンスが高いと感じた Jenkins・GitLab CI・Azure Pipelines・AWS CodePipelineを含む幅広いCI/CDツールに対応 HyperExecuteによる超高速な並列テスト実行が可能 弱み 実機デバイスの実際の可用性がBrowserStackに比べると劣る場合がある テスト分析レポートの詳細度が競合より低く、根本原因分析に限界がある UIのナビゲーションが複雑で、習熟に学習コストがかかる ::: 総合評価と推奨 現状のチーム状況（非エンジニアメンバーでも扱いやすいこと、Web・モバイルアプリの両方に対応できること）を踏まえた評価です。 ツール 評価 推奨優先度 コメント LambdaTest ★★★★☆ 第1候補 AI機能、コスト、幅広いCI/CD連携の観点から、現状のチームに最も適している CloudBeat ★★★★☆ 第2候補 コードレス機能が充実。ただし、モバイル対応やサポート面は追加確認が必要 BrowserStack ★★★☆☆ 将来候補 エンジニア体制が拡充した場合の有力な候補 Sauce Labs ★★☆☆☆ 保留 現状のチーム構成では導入ハードルが高く、コスト面でも慎重な検討が必要 感想・学び 海外カンファレンスならではの気づき :::message 現地ではコミュニケーション手段としてLinkedInが主流で、名刺交換の機会はあまり多くありませんでした。 現地で知り合った方とは、LinkedInで連絡先を交換しました。海外エンジニアとのつながりを作る際は、事前にLinkedInのプロフィールを整えておくことをおすすめします。 ::: 現地での交流から得た、世界のQA事情についての気づきも多くありました。 開発とQAを兼務しているエンジニアが多い — 日本のように専任QAチームが分離している体制は珍しく、開発者自身がテストも担う形が世界的には一般的なようです ノーコードの自動化ツールを利用している人は少数派 — コードを書いてテストを自動化するスタイルが主流で、ノーコードツール利用者は少数派という印象でした 自動化テストの現状と課題 :::message alert 世界のAppiumユーザーの声：「自動化テストをやめるべきか考えている」という方もいました。 理由は Flaky Test （不安定なテスト）の問題です。今回成功しても次回失敗する、という繰り返しによって、テスト自動化そのものへの信頼が揺らぐケースが世界的にも多いようです。 ::: Flaky Testは自動化テストにおけるグローバルな課題であり、その解消こそが現代のテストエンジニアに求められていることを、改めて実感しました。AIツールを活用した根本原因分析や、要素特定用のIDを活用した安定したテスト設計が、この問題への有効なアプローチとなるでしょう。 まとめ 約8ヶ月の準備を経てバレンシアの国際舞台に立ち、世界中のエンジニアとKINTOテクノロジーズの取り組みを共有できたことは、自分にとって大きな経験となりました。セッションで得た知識・現地での人脈・ツール各社との情報交換、そして自分の発表への反響——すべてが今後の業務に活きる財産です。来年のSeleniumConfにも引き続き注目していきたいと思います。

はじめに こんにちは、2026年3月入社の大園です！ 本記事では、2026年3月入社のみなさまに入社直後の感想をお伺いし、まとめてみました。 前の方からの質問に次の方が答えるリレー形式でお届けします。 KINTO テクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ 大園博昭  自己紹介 Engineering Officeの大園です！ Xは こちら 会社横断での経営・組織課題を解決するという幅広いミッションを受け持つチームの中で、主にソフトウェアテスト周りや生成AI周りの技術部分を担当しています 所属チームの体制は？ 上長が名古屋、他チームメンバー3人が東京、私が福岡所属と全国に散らばっています やっていることは全員バラバラの個人商店なチームですが、毎日ZoomやSlackでワイワイやっております KTCへ入社したときの第一印象？ギャップはあった？ 入社前からいろんな話を聞かせていただいていたのと、自分がどんなことで貢献できそうかというイメージをしっかり持っていたため、特に大きなギャップはなかったです。 現場の雰囲気はどんな感じ？ 福岡オフィスは去年できたばかりというのもあり、人数もまだ10人未満。自分たちで一から作っている感が楽しいです！ ブログを書くことになってどう思った？ 今後どんどん書いていきたいと思います！ ブログではないですが、6/4に福岡オフィスにおいてE2Eテスト x AIというテーマで 勉強会を開催しました 。今後もKINTOテクノロジーズの魅力発信や福岡エンジニアを盛り上げる活動を積極的にしていきたいと思います！ 高さん ⇒ 大園さんへの質問 福岡の豚骨らーめんの中で、一番美味しい店について教えてください これは戦争が起きかねない非常にセンシティブな質問ですね…私は昔ながらのとんこつラーメンが好きなので 元祖長浜屋 です！ 森重香一  自己紹介 業務システム開発部業務システムGの森重です。 KINTO事業のシステムのうち、債権領域のビジネスアナリスト（BA）を担当しています。 BAは開発チームと業務部門の橋渡し役で、要件整理や関係者調整が主な仕事です。 大阪オフィス勤務で、前職は業務システム開発に携わっていました。 所属チームの体制は？ 直属チームは4名（東京3名・大阪1名）で、同期入社の田平さんも同じチームです。 田平さんの紹介と合わせて読んでいただけると体制がより伝わるかと思います。 離れていても Slack やオンラインミーティングで日々連携できています。 KTCへ入社したときの第一印象？ギャップはあった？ 「テックベンチャー」という言葉から、技術中心で少し距離感のある組織をイメージしていました。 実際に入社してみると、勉強会や交流イベントが多く、所属チーム外の方とも自然に話せる機会がたくさんありました。 良い意味でイメージとのギャップを感じています。 現場の雰囲気はどんな感じ？ 落ち着いた雰囲気の中で、それぞれが主体的に動いている印象です。 困ったときは気軽に相談できますし、Confluence や Slack を活用した情報共有が活発で部門を超えて動きやすいです。 個人で進める部分とチームで議論する部分のバランスが良いと感じています。 ブログを書くことになってどう思った？ これまで読む側だったので、書くのは少し緊張しました。 ただ振り返ってみると、入社後の気づきを言語化する良い機会になりました。 入社を検討されている方に少しでも雰囲気が伝わればうれしいです！ 大園さん ⇒ 森重さんへの質問 最近行った旅行でオススメの観光地などあれば教えてください！ 昨年末に友人と犬山城へ行きました。 今年の大河ドラマ「豊臣兄弟！」が始まることもあり、放送前に戦国ゆかりの地を訪れてみようと思ったのがきっかけです。 実際に訪れてみると、テレビや写真で見るよりも天守はコンパクトな印象でしたが、その分、現存天守ならではの歴史をぐっと身近に感じることができました。 黒い外観も印象的で、少し離れて見ると存在感がありました。 城下町は大規模な観光地というより歩きながらゆっくり楽しめる雰囲気で、食べ歩きや散策をしながら半日ほど過ごせます。名古屋からのアクセスもよく、週末の小旅行としておすすめです。 佐藤誠  自己紹介 プラットフォーム開発部xREグループDBREチーム 所属の佐藤誠です。 KTCのDBRE業務全般を担当してます。AWS Aurora MySQLをたくさん使っていますが、PostgreSQLも社内で安全に使えるように整備を進めています。 所属チームの体制は？ DBREチームは5名体制で、全員神保町所属です。 KTCへ入社したときの第一印象？ギャップはあった？ 入社前にオフィス見学などもさせてもらっており、印象通りでした。 現場の雰囲気はどんな感じ？ 神保町オフィスはいわゆる古書街から少し南に下ったところにあり、オフィス周りを歩くだけで発見がたくさんありますね。ラーメン、カレー、中華、洋食も名店がたくさんあり、ランチは毎日の楽しみです。オフィス内はまだ知り合いが少ないのでこれからですが、皆さんシゴデキな雰囲気があります。 ブログを書くことになってどう思った？ いつ来るかと思ってたら入社して3か月経ってました。 森重さん ⇒ 佐藤さんへの質問 散歩が趣味とのことですが、歩いていて起きた忘れられない出来事やハプニングがあれば教えてください！ 道を聞かれたり、駅近だと寸借詐欺っぽいことはよくあるくらいですかね。。。散歩の醍醐味としては駅間の移動が点の移動に対して、徒歩は線・面の移動になるので、いろいろな気づきがありますね。雰囲気の良い公園とか地元の小さな雑貨屋が見つかったり。河川敷とか線路沿いをよく歩きますが、人の営みを感じられて良いです。 田平亨斗  自己紹介 業務システム開発部業務システムGの田平です。 KINTO事業のシステムのうち、与信領域の開発・運用を担当します。 東京の室町オフィス勤務ですが、最近は神保町にいることも多いです。 所属チームの体制は？ 直属のチームは4名体制で、東京3名大阪1名です。 加えて、他の部や協力会社の方に入っていただいている形です。 KTCへ入社したときの第一印象？ギャップはあった？ 入る前はもっとトヨタ色が強いと思っていました。実際は逆で、そういった物に縛られない集団を目指していると認識しています。 案外車に乗ってない方も多い印象。サーキットを走られているような方もいて多様性があると思います。 現場の雰囲気はどんな感じ？ 中途採用で経験豊富な方ばかりで、落ち着いた印象です。 オフィスごとに結構雰囲気も違いそうで、色々行ってみたくはあります。 ブログを書くことになってどう思った？ 選考時から存在は知っていたのですが、入社後無事こうしてブログを書けているのがまずは良かったという感じです。 佐藤さん ⇒ 田平さんへの質問 明治大正の建物のおすすめがあれば教えてください（迎賓館赤坂離宮は自分も大好きです） なんといっても上野・湯島の旧岩崎邸庭園がオススメです。都会の喧騒を離れた落ち着いた環境で、装飾やタイル、金唐革紙など見どころが多い所です。 昭和初期にはなりますが、白金台の庭園美術館（旧朝香宮邸）も赤坂離宮と同様に豪奢な印象、アールデコの装飾が非常に多く見応えがあるかと思います。 ついでに大阪あたりだと芦屋のヨドコウ迎賓館が非常にオススメ。福岡はめちゃくちゃ現代ですが、天神地下街が素晴らしい。名古屋には何と言っても明治村があります！ 高斯  自己紹介 デジタル戦略部 データサイエンスGの高（si gao）です。 データ分析を担当しています。 東京オフィス勤務です。 趣味：サッカー観戦 / プレー / 漫画アニメ鑑賞 / ゲーム 所属チームの体制は？ デジタル戦略部のデータサイエンスGに所属し、データ分析を担当しています。 チームは3名体制です。 分析に使っている言語・ツール例：Python / SQL / BIツール など。 KTCへ入社したときの第一印象？ギャップはあった？ 入社前はもっとお堅い雰囲気を想像していました。実際はフラットで風通しがよく、データやテクノロジーで事業を前に進めようという空気の強い組織だと感じました。 エンジニアやデータ分野のスペシャリストが多く、それぞれの専門性を持ち寄って課題に取り組んでいる点が良い意味でのギャップでした。 現場の雰囲気はどんな感じ？ 落ち着いていて相談しやすい雰囲気で、分からないことを聞きやすい環境です。 東京オフィスは設備も整っていて働きやすく、チームを越えた交流の機会もあります。 ブログを書くことになってどう思った？ 入社して間もないタイミングで、自分の言葉で会社や仕事を振り返る良い機会になりました。 リレー形式で前の方からの質問に答えるのが新鮮で、楽しく書けました。 田平さん ⇒ 高さんへの質問 サッカーかなりお好きなのではないかと思いますが、どういった所に魅力を感じていますか？ 大きく3つあります。 どんな体型・体格の人でも活躍できるところ 。背が高くなくても、足が特別速くなくても、技術や判断力、ポジショニングで輝ける選手がたくさんいます。多様な個性が同じピッチで成立するのがサッカーの面白さだと思います。 想像力が問われるところ 。次のプレーを読み、スペースを作り、味方の動きを予測する——決まった正解のない中で発揮される創造性に毎回ワクワクします。 チームワーク 。一人のスター選手だけでは勝てず、全員が役割を全うして初めて勝利に近づく。個と組織のバランスが取れた瞬間の美しさが一番の魅力です。 さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

1. はじめに Quality Engineering Gのとみよしです。 私が所属するQAチームではオープンソースのテスト管理ツールであるTestLinkを採用しています。 :::message TestLinkとは テストケースの作成・管理からテスト計画の立案、実行結果の記録まで一元管理できるオープンソースのテスト管理ツールです。 ::: TestLinkへの結果入力は工数がかかるため、Excelマクロで結果を一括入力できるXMLファイルを生成する仕組みを運用していました。 しかしこのExcelマクロには2つの課題がありました。 チーム内にMac・Windowsユーザーが混在しており、OS差分を考慮した 2本のコードを管理 しなければならなかった ローカル環境でのみ動作するため、 更新のたびにファイル共有が必要 だった これらを解決するために、Microsoft 365のCopilotを活用してGoogle Apps ScriptでWebアプリを作ってみました。 コードは一行も自分で書いていません。 その過程を紹介します。 2. 解決策としてGAS Webアプリを選んだ理由 課題の本質は「 環境に依存している 」ことでした。ブラウザで動くWebアプリにすれば、OSの違いもローカル管理の問題も一度に解決できます。 その中でGAS（Google Apps Script）を選んだ理由は主に3つです。 ① OS差分がなくなる ブラウザで動くため、MacでもWindowsでも同じように使えます。 ② Google スプレッドシート（以下、GSSと表記）と連携できる プロジェクトコードや担当者などのマスタデータをGSSで管理し、Webアプリからそのまま参照できます。更新もGSS上で行うだけなので、誰でもマスタ更新が可能になります。 ③ 無料で使える Google アカウントがあれば追加コストなしで開発・運用できます。 3. 完成したWebアプリの紹介 主な機能は3つです。 ① 一括生成 テストケースが連番になっている場合に使います。開始番号と終了番号を入力するだけで、その範囲をまとめたXMLファイルを出力できます。 例）No.1〜100をまとめて一括出力 ② 個別生成 テストケースを個別に指定して出力します。飛び番号のケースや、特定のケースだけ再テストしたい場合に便利です。 例）No.1, 3, 5, 7, 10を個別に出力 ③ マスタ管理 プロジェクトコードや担当者名をGSSで管理しています。画面右上の「マスタを編集」ボタンからGSSに直接遷移して編集できます。 4. 開発の進め方 〜Copilotと約15往復した話〜 「WebアプリはGASで作ろう」と決めたものの、私は簡単なGASのコードしか書けず、Webアプリに関する知識はほとんどありませんでした。そこで活用したのが Microsoft 365のCopilot です。 Copilotへの最初の一手 まず既存のExcelマクロのコードをそのままCopilotに貼り付け、以下のように依頼しました。 「このExcelマクロと同じ機能をGAS（Google Apps Script）で書いてください」 たったこれだけです。Copilotは既存コードの意図を読み取り、GAS向けのコードを出力してくれました。 Excelマクロという既存の資産がそのまま設計書代わりになった わけです。 機能を1つずつ育てていった 最初から全機能を一度に作ろうとせず、以下の順番で1つずつ機能を追加していきました。 一括生成機能の作成 個別生成機能の追加 マスタ機能の追加 細かい仕様の追加 Webアプリ化 1ステップずつCopilotに依頼し、動作を確認してから次に進む流れです。結果的に 10〜20往復 のやり取りになりました。 エラーが出たらそのまま貼り付ける 開発中にエラーが発生することも何度かありましたが、対処法はシンプルです。 エラーメッセージをそのままCopilotに貼り付ける それだけで原因の説明と修正コードを返してくれました。エラー対応は 1〜2往復で解消 できました。 5. やってみて気づいたこと Copilotへの伝え方のコツ 一度に複数のことを依頼するより、 1つの依頼につき1つの機能追加 に絞ったほうがスムーズでした。欲張って「あれもこれも」と依頼すると、意図が伝わりにくくなることがありました。 QAエンジニアでもWebアプリが作れた 着手前は「自分にWebアプリなんて作れるのか」という不安がありました。しかし Copilotに既存のコードを渡してやり取りを繰り返すだけで、気づけば動くWebアプリができあがっていました。 プログラミングの専門知識がなくても、「何をしたいか」を言葉で伝える力があれば十分です。 Before / After Excelマクロ GAS Webアプリ OS対応 Mac/Windows別管理 ブラウザで統一 コード管理 実質2本 1本 マスタ管理 Excelファイル Google スプレッドシート 共有のしやすさ ファイル共有が必要 URLを共有するだけ 「はじめに」で挙げた2つの課題が、どちらもきれいに解消されました。 6. おわりに 「QAエンジニアにはコードが書けない」なんてことはありません。 AIを活用すれば、 既存の資産を渡すだけで新しい環境向けのコードを生成してもらえます。 私自身、コードを一行も書かずにWebアプリを完成させることができました。 同じようにExcelマクロの管理に悩んでいるQAエンジニアの方がいれば、ぜひ一度試してみてください。まず手元にあるマクロのコードをCopilotに貼り付けるところから始めれば大丈夫です。 この記事が、AIを活用した業務改善の第一歩を踏み出すきっかけになれば嬉しいです。

はじめに QE（Quality Engineering）グループのMobileチームのokapiです。 Claude Codeがあれば、もうAIはこれ一本でいいよね？ そう思ってました。 仕様整理、テスト設計、業務効率化アプリ（GASでWebアプリ）の開発も、Claude Codeがあると進めやすくなりましたし、 社内で話していても「Claude Code便利」という話をいろんな方から聞いてました。 そんなある日、社内で「Gemini CLIを検証できる」タイミングがありました。 最初は、一緒に作業しているメンバーが使いたいと言っているので、ついでに試そうくらいな感じでした。 :::message 「Claude Codeで困ってないし、Geminiは必要？」 ::: ふと思ったんですが、 :::message 「Claude Codeを毎日使っているからこそ、できなかった所をGeminiで解消できたり……？」 ::: そんな好奇心から、QEグループとして「Claude Code × Gemini CLI」の併用効果を検証してきました。 結果、当初の予想を超える発見がありました。本記事では、その結果をお伝えします。 Gemini CLIとは？ :::message alert 【公開時点での重要なお知らせ】 Gemini CLIは「2026年6月18日」でリクエスト受付が終了し、後継の Antigravity CLI に移行されました。 ※法人向けは引き続き利用可能です。 ::: Gemini CLIは、Googleが提供する生成AI「Gemini」をコマンドライン(CLI)から使えるツールです。 普段Webブラウザで触るチャットUIとは違い、ターミナル上で対話できるのが特徴です。 Claude Codeとの主な違いを整理するとこんな感じです。 ツール 強み 弱み Claude Code コード生成・リファクタ・レビューが得意。仕様理解や論理的な推論に強い 動画解析ができない。20ページ超のPDFは苦手。Web検索の鮮度がやや弱い Gemini CLI 動画・画像・大容量PDFを一括解析できる( analyzeFile )。Google検索で最新情報を取得( googleSearch ) コード生成はClaude Codeで十分なケースが多い こちらの「Claude Code」の弱みを「Gemini CLI」で解消して、 「Claude Code」をさらに使いやすくするのが、今回の検証の狙いです。 graph LR A[Claude Code] B[Gemini CLI] A -.-> X[動画解析] A -.-> Y[50ページ超PDF] A -.-> Z[最新Web情報] B ==> X B ==> Y B ==> Z X --> R[Claude Code × Gemini CLI<br/>QA業務の幅が広がる] Y --> R Z --> R style A fill:#dae8fc,stroke:#6c8ebf,stroke-width:2px style B fill:#ffe6cc,stroke:#d79b00,stroke-width:2px style R fill:#d5e8d4,stroke:#82b366,stroke-width:2px linkStyle 0 stroke:#6c8ebf,stroke-width:1.5px linkStyle 1 stroke:#6c8ebf,stroke-width:1.5px linkStyle 2 stroke:#6c8ebf,stroke-width:1.5px linkStyle 3 stroke:#d79b00,stroke-width:3px linkStyle 4 stroke:#d79b00,stroke-width:3px linkStyle 5 stroke:#d79b00,stroke-width:3px linkStyle 6 stroke:#aaa,stroke-width:1px linkStyle 7 stroke:#aaa,stroke-width:1px linkStyle 8 stroke:#aaa,stroke-width:1px 🔵 点線：Claude Codeの弱み　／　🟠 太線：Gemini CLIの強み 検証の進め方 社内のAI検証プロジェクトの一環として、以下の流れで進めました。 項目 内容 検証期間 3週間（2026年4/20〜5/8） 検証ユースケース Claude Codeとの併用（Claude Code × Gemini CLI） 検証方法 同じQA作業を「Claude Code単独」と「Claude Code × Gemini」の両方で実施し、結果を比較 記録方法 Confluenceに検証レポートとして記録 :::message Claude Code内にGemini CLIのMCP（外部ツール連携）を構築することで、 ツールを切り替えずにClaude Code内でGeminiが使えるようになります。 ::: 検証結果まとめ :::message Claude Code単体で使うよりも、Geminiを併用した方がQA作業を効率化できました。 ::: 検証した7つのユースケースを、効果が大きかったものから紹介していきます。 No. ユースケース Claude Codeのみ Claude Code × Gemini併用 コメント 1 動画解析 ❌ ✅ Claude Codeでは不可。Geminiを入れることで可能に 2 ダブルチェック ❌ ✅ Claude CodeとGeminiの視点でレビューできる 3 QA設計（大容量PDF） ⚠️ ✅ 50ページ超の仕様書も一括解析可能に 4 画像解析 ⚠️ ✅ 大容量・複数画像の一括処理が可能 5 Web検索 ⚠️ ✅ 最新情報を効率よく収集 6 並列処理 ⚠️ ✅ 重い処理をバックグラウンドに逃せる 7 コード生成 ✅ ✅ ここはClaude Codeのみで十分 それぞれを少し詳しく紹介します。 効果が大きかった併用パターン 1. 動画解析：Claude Codeのみでは不可。Geminiを入れることで可能に これが一番大きいポイントです。 Claude Code単独では、動画ファイルを直接解析することはできませんが、 Gemini CLIの analyzeFile を使うと、「音声・映像をまとめて解析」できます。 QA業務では「動画」を扱う場面が意外と多いです。 たとえば、 登壇練習動画を見て、話し方や資料の流れをレビュー JIRAの不具合チケットのエビデンスから内容を確認してもらい手順をテキスト化 新しいツールの使い方などの手順を聞くときに動画から詳細手順を確認 が新たにできるようになりました。 :::message 補足：Claude Code単独では動画解析はできませんが、Skills（拡張機能）を使えばClaude側でも対応自体は可能です。 Claude Code：Claude Skills（ claude-video-vision など）を使い、「動画をフレーム画像に分解してから解析する」という形で対応 Gemini CLI：動画ファイルをそのまま読み込んで、映像と音声を同時に理解。操作の因果関係や正確なタイムスタンプの特定も可能 そのため、動画解析はGeminiで行うのがおすすめです！ ::: 2. ダブルチェック：Claude CodeとGeminiの視点でレビューできる Claude Codeに「Confluence資料のレビューして」とお願いしても、同じセッション内では同じ視点でしかチェックできません。 つまり、Claude Codeが見落とした観点はそのまま見落とされてしまうんです。 そこで、Geminiの chat を併用すると、独立した第三者の視点でレビューしてもらえるようになりますので、 テスト設計やドキュメント修正をする時に、役立ちました。 Claude Codeで作成 Claude CodeとGemini CLIでレビュー 指摘内容をClaude Codeで反映 という流れにすると、Claude CodeのハルシネーションをGeminiが指摘してくれるので、より正確になります。 「人にレビュー依頼する前に」Claude Code × Geminiが代わりにダブルチェックしてくれるので精度が上がりました。 3. QA設計（大容量PDF）：50ページ超でも一気に解析 QA設計では、操作手順書やイベント仕様書など、ページ数が多いPDFを読むことが頻繁にあります。 Claude Codeのみだと、20ページのPDFが上限で、それ以上だと読んでいなかったりすることがあるので、 分割して渡したり、md形式に変換したりと、ひと手間必要でした。 Gemini CLIの analyzeFile を使うと、50ページ超のPDFも一括で解析できます。 案件の仕様整理でも、必要な観点を抽出できました。 4. 画像解析：大容量・複数枚の一括処理 Figmaのデザイン画像やスクリーンショットを、AIに見せて確認してもらうケースは多いです。 Claude Codeのみでも画像は読めるのですが、大容量や複数枚をまとめて処理するのは少し苦手でした。 Geminiの analyzeFile を使うと、複数の画像を一気に渡してまとめて分析できます。 QAの表示確認テスト設計では、複数画面のFigmaデザインをまとめて確認した上、設計できるようになりました。 5. Web検索：最新情報を効率よく収集 Claude Codeにも組み込みのWeb検索機能はありますが、確認範囲が狭めで、たまに古い情報を返してくることがありました。 Geminiの googleSearch は、Google検索を直接使うので、最新情報を効率よく収集できます。 6. 並列処理：重い処理をバックグラウンドに逃せる 動画解析や大容量PDF解析は、どうしても時間がかかります。 Claude Codeのみで重い処理を回している間、メイン作業が止まってしまうのが地味にストレスでした。 Claude Codeにもサブエージェント機能はありますが、Geminiをサブエージェントとして併用すると、Claudeが苦手な動画や大容量PDFを任せられるだけでなく、Claudeのコンテキストを圧迫せずに重い処理を進められるメリットがあります。 また、別のAIモデルが裏で動いてくれるので、Geminiが動画解析している間もClaude側でテスト設計を進められるなど、メイン作業を止めずに並行作業できる（スピード早い）点も便利でした。 ここでは「Claude Code → Geminiサブエージェントに重い処理を委譲」という役割分担で活用してます。 効果が変わらなかったパターン コード生成：Claude Codeのみで十分 コード生成についてはClaude Codeのみで困りませんでした。 Webアプリ作成や自動化コードのレビューは、Claude Codeだけでも問題なく進められており、Geminiを足しても大きな差は感じませんでした。 「全部Geminiに頼った方がいい」というわけではなく、 得意分野を見極めて使い分けるのが大事だと感じます。 検証してわかったこと 「単独 → 併用」で何が変わる？ 3週間使ってみた感想を、表に整理しました。 観点 Claude Codeのみ Claude Code × Gemini併用 扱える資料の範囲 コード・テキスト・画像・短いPDF 動画・大容量PDF・複数画像 レビューの質 自己レビュー（同一視点） 独立した第三者視点 情報の鮮度 やや古い情報を含むことあり 最新情報を効率よく収集 作業の並列性 サブエージェント並列は可能 重い処理をバックグラウンド処理 初心者が始めるなら、どう使い分ければいい？ 「全部のユースケースで併用」となると、最初はハードルが高いので、 まずはClaude Codeを日常使いの主軸にして、以下のシーンでだけGeminiを呼び出すスタイルがおすすめです。 シーン 使うツール 普段のコード生成・テスト設計 Claude Code 動画を扱う時 Gemini CLI（ analyzeFile ） 50ページ超のPDFを扱う時 Gemini CLI（ analyzeFile ） 重要な変更のダブルチェック Gemini CLI（ chat ） 最新情報の調査 Gemini CLI（ googleSearch ） 上記で使ってみて、慣れてきたら使う場面を広げていきましょう。 おわりに 「Gemini CLIを社内検証で使ってみた！」というテーマで、 Claude Codeとの併用効果を紹介しました。 今後もAIを活用して、QA業務の効率化を進めていきたいと思います。 これからGemini CLIを試してみる方の参考になれば嬉しいです！

はじめに こんにちは。KINTOテクノロジーズ（以下、KTC）の AIファーストG に所属している、野村宏樹です。 このたび、2026年6月1日付で Microsoft MVP（Most Valuable Professional）を Microsoft Foundry カテゴリ で受賞しました。Azure 上での生成AI／AIエージェント開発を中心に発信してきた活動を評価いただいたもので、とても光栄に思っています。本記事では、受賞のご報告と、その背景にあったKTCでの活動についてご紹介します。  Microsoft MVP として届いたトロフィー 受賞の証として、MVPプロフィールも公開されています。 https://mvp.microsoft.com/ja-JP/mvp/profile/93ebd9f1-a8c0-492c-8cc2-adc7f5f980e9 Microsoft MVP プロフィールページ Microsoft MVP とは Microsoft MVP は、Microsoft 製品・技術に関する深い知見と、技術コミュニティへの継続的な貢献を称えて Microsoft 社が「個人」に授与するアワードです。直近およそ1年間の活動が審査対象で、毎年の更新審査があります。技術領域ごとにカテゴリが分かれており、世界で約 3,000 名が受賞しています。受賞すると、製品の早期アクセスや製品チームと直接つながれるチャネル、年次の Global MVP Summit への招待などの機会があります。 私が受賞した Microsoft Foundry カテゴリ は、比較的新しいカテゴリ名です。 :::message Microsoft Foundry のカテゴリーは、Azure 上で生成AIアプリやAIエージェントを開発するための基盤に関する領域です。Azure AI Foundry がリブランディングされたもので、モデルやエージェントの開発・運用をまとめて扱うエコシステムを指します。 ::: 受賞につながった活動：KTCのカルチャーに支えられて 今回の受賞は、KTC の Output文化・登壇文化 、そして全社的に生成AIの業務活用を進めている環境に、大きく後押ししていただいたものでした。2025年8月にKTCへ入社して以来、「やってみたことを外に出す」「登壇して共有する」が当たり前にある雰囲気のなかで、自然と活動を続けることができました。 発信は、大きく2つの軸で行ってきました。 ① KTC事例の共有 KTCでは2023年から社内向けの生成AIチャットツールを導入し、全社で生成AIの活用を進めています。その現場で得た学びを、たとえば「社内で使うチャットアプリを自分たちで内製する意義」といったテーマで共有してきました。このテーマは、NoMaps 2025（札幌）で当時のチームリーダーである和田颯馬さんと共同で登壇しています。 https://no-maps.jp/program/tech/121500/ 社内で使うものを自分たちの手で作るからこそ、現場のフィードバックを素早く反映でき、業務に本当に必要な形へ磨き込んでいけます。そうした内製ならではの価値を、実体験ベースでお話ししました。 ② ユースケースを軸とした技術活用の共有 個人的に「面白い」「使えそう」と感じた技術を PoC で試し、ブログにまとめ、少し抽象化したものを登壇してOutputする、というサイクルで発信してきました。テーマは MCP（Model Context Protocol）、マルチエージェント（AutoGen / Microsoft Agent Framework）、Azure AI Foundry エコシステム、ローカルLLM／SLM（Foundry Local・phi-4）など。単に「何ができるか」だけでなく、 どんなユースケースで、どう使うか まで踏み込むことを意識しています。 コミュニティ活動としては、KTCが主催する 名古屋LLM MeetUp をはじめ、なごあず（JAZUG 名古屋支部）、JAZUG、すきやねん Azure など各地のコミュニティで登壇させていただきました。2025年度は個人として、ブログ31本・登壇11回ほどの活動になりました。 2025年度の登壇は以下のとおりです。 日付 イベント タイトル 2025/6/21 なごあず（JAZUG 名古屋支部） AzureでMCPサーバ！！どう活用する？ 2025/7/23 名古屋LLM MeetUp（KTC主催） チャットアプリ失敗談！製造業業務への生成AI導入 2025/8/16 JAZUG×なんでもCopilot #jaznancopa Azure AI Foundry Portal デモ 2025/9/15 NoMaps 2025（札幌） 生成AI最前線：最新トレンドと活用事例（和田颯馬さんと共同） 2025/11/21 名古屋LLM MeetUp（KTC主催） AzureでのAIエージェントはここから！Azure Functions × AI 2025/11/27 YonaAz AzureでAIエージェント、さて何から始める？ 2025/11/29 JAZUG Shizuoka リアルタイム音声モデル gpt-realtime を使った音声対話ツール 2025/12/6 なごあず（JAZUG 名古屋支部） ローカルとクラウドLLMのハイブリッドAI活用 2025/12/26 すきやねんAzure ハイブリッド構成 Queue Polling 2026/2/28 AgentCon Tokyo エージェント開発とライフサイクル管理 ～構築から AgentStore 基盤まで～ 2026/3/14 なごあず（JAZUG 名古屋支部） gpt-realtime-1.5 モデルでスタックチャン これから これからも、 「どう使うか（ユースケース）」を大事にしながら、技術のOutputを続けていきたい と思っています。AIにより技術のキャッチアップや開発は非常にしやすくなっています。大事なのはその手段をどこにどう使うと価値がでるのか？だと思っています。引き続きAzure・生成AI・AIエージェント領域の技術を突き詰めながら、ユースケースを軸にした発信を続けていきます。 改めて、日々の活動を支えてくれているKTCの環境と、関わってくださったみなさまに感謝します。 発信内容は、個人のZennにもまとめています。よろしければこちらもご覧ください。 https://zenn.dev/nomhiro 最後に KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！ 最後までお読みいただき、ありがとうございました。