• 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     ┘

設計は 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 つもありません。

どのフレームワークを選んでも、動画をデコードするのは 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 はゼロコピー直結と引き換えに手動のレイヤー管理を受け入れる

両者の得失は明確に非対称です。

この表を頭に入れたうえで、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 に下りて実装しました。まず実装量の実態を見てください。

モバイル側の録画は 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 プラットフォームに出荷できる水準にあります。この記事の数字とコードが、同じ判断を迫られている方の材料になれば幸いです。

最後まで読んでいただき、ありがとうございました！

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つの価値を狙いました。

3つ目が本プロジェクトの特徴的なポイントです。単にテンプレを作るのではなく、すでに個人が生み出していたAI-Nativeな工夫を「会社公式」の標準にすることを重視しました。AI-Native Devが文化醸成の軸として掲げてきた「個人の知見を組織全体で活かす」を、パワポテンプレという誰にとっても身近な題材で実践した形です。

体制と進め方

推進はAI-Native Devが担い、テンプレートのデザインはクリエイティブグループが担当する協業体制で進めました。今後は技術広報グループとも連携しながら、利用促進に取り組んでいく予定です。

全体像は次のとおりです。

進め方として特に大事にしたのは、次の合意です。

「AIで再現しやすいフォーマット / スタイルガイドはどうあるべきか」をAI利用者側から逆算してデザイナーへインプットし、デザイナーがそれを受けてフォーマットを設計する。

デザインが完成してからAIに対応させるのではなく、設計の段階から「AIが出力しやすい構造」を要件に含めています。この取り組みを「AI-Native」と呼んでいるのは、こうした進め方によるものです。

フェーズは次のように区切りました。

いきなり完成品を作るのではなく、まず有志の自作テンプレをたたき台として展開してフィードバックを集め（公開後50名以上が閲覧・ダウンロード）、その声をもとに公式版を作る、という2段階を踏んでいます。

AIが利用しやすいテンプレートの設計

完成したテンプレートには、AIとの相性を高めるための工夫がいくつも入っています。

ヘッダー＋ボディのコンポーネント構造

スライドを「ヘッダー＋ボディ（シングル / スプリット / マルチカラム）」というコンポーネントの組み合わせとして構造化しました。AIは自由なレイアウトを毎回ゼロから作るよりも、決められた部品の組み合わせを選ぶ方が安定して高品質な出力を返せるためです。

レイアウト選択ルールのスキル化

「どんな内容のときに、どのレイアウトを選ぶべきか」というルールをClaudeのSkill（スキル）として整備しました。これにより、毎回テンプレファイルを渡さなくても、Claudeが自律的に適切なレイアウトを選択してスライドを組み立てられます。

使い方は3通り

展開にあたっては、作業スタイルに合わせて3通りの使い方を用意しました。

方法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」 が開催されました。私は会場提供・運営サポートを担当しつつ、参加者としてハンズオンにも取り組みました。

本記事は、その開催報告です。

 当日のエントランスの様子

開催したイベントの概要

タイムテーブルは次のとおりです。

会場提供の経緯

主催の森田さんは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つです。

ハンズオンも「エージェントを作る → 環境を作る → セッションを起動する → メッセージを送る」という順番をそのままたどる構成になっていたので、この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月にも開催されます。

解説のあとハンズオンという流れは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テクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくはこちらからご確認ください！

社内で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に触れる

午後の部（3時間）・・・AgentCoreとMCPを実践する

社内実施にあたって変更が必要だったポイント

書籍のハンズオンをそのまま社内で実施するにあたり、いくつか環境差異への対応が必要でした。

:::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エージェント開発に取り組む方や、同様のワークショップを企画する方の参考になれば幸いです。最後までお読みいただき、ありがとうございました。

先日、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