はじめに
2026年4月8日、大阪駆動開発さん主催のオンラインイベント「AIミーティング(#AIMTG)」でLT登壇してきました。
大阪・北海道・福岡・熊本など各地のコミュニティがZoomで接続され、AIに関する取り組みや自作アプリを披露し合う場です。全国のパブリックビューイング会場と繋がるスタイルは、オンラインLTなのに妙な臨場感があって面白い体験でした。
LTのタイトルは 「生成AIと僕、どっちが賢いか対決してみた。」
世間がChatGPTだ、生成AIだ、チャッピーだと騒いでいるので、僕の方が賢いことを証明する(※個人の見解です)という趣旨で、AIに3本勝負を挑みました。この記事では、その顛末と、負けを通して見えた「今のAIの正しい理解」をまとめます。
作戦:AIの「構造的な弱点」を突く
勝負を挑むにあたり、まず敵の仕組みを整理しました。生成AIとは、大量のテキストを学習して確率的に「それっぽい」回答を返すシステムです。ここから導かれる弱点は2つ。
- 学習データに締め切りがある — カットオフより後の情報は知らない。昨日のニュースも今日の天気も知らないはず
- 「正確」ではなく「それっぽい」 — 次に来る単語の確率を計算しているだけなので、自信満々に間違える
「博識だけど、たまにハッタリをかます」——弱点があるなら勝負できる。そう考えた僕は、この2点を突く作戦を立てました。
Round 1:「今日の大阪の天気は?」
最初の勝負はリアルタイム情報です。学習データの締め切りがある以上、今日の天気など知りようがないはず。
チャッピーの回答は「大阪は雨です」。
僕は鼻で笑いました。「過去のデータしか知らんやろ。傘なんていらねぇ」と手ぶらで外に出ました。
外は本当に雨でした。
判定:僕の負け。
なぜ負けたのか:エージェント機能
「生成AIはリアルタイム情報を知らない」という僕の前提は、すでに過去のものでした。最近のAIにはエージェント機能があり、自律的にWebを検索して最新情報を取ってこられます。
エージェントの動きはこうです。
- 考える — 「何を調べれば答えられるか」を自分で判断
- 調べる — Webを自律的に検索して最新情報を取得
- 答える — 情報を統合して回答を生成
- 繰り返す — 必要なら何度でもループして精度を上げる
従来のAIが「知識を出すだけ」だったのに対し、エージェントAIは自分で動いて答えを作りに行く。僕は敵を知らずに戦っていました。
AWS視点で見ると
この仕組みはAmazon Bedrock Agentsのアーキテクチャそのものです。Orchestration LayerがReActループ(推論→行動→観察)を回し、Action Groups経由でLambdaから外部APIをリアルタイム呼び出しし、Knowledge Bases(OpenSearch / Aurora)でRAGを実行、Guardrailsで出力を制御して回答を返す。
つまり「AI」と一言で言っても、実態は基盤モデル層・API層・アプリ層の3層構造であり、僕が戦っていた「チャッピー」はアプリ層。素の基盤モデルは天気を知らなくても、アプリ化された時点でWeb検索担当・ツール実行担当を従えたチーム戦になっていたのです。
Round 2:造語トラップ「ワショク・バイアス」
作戦変更です。「Webを検索するなら、Webに嘘を仕込めばいい」。
僕は自分のGitHub Pagesに架空のAI用語を仕込みました。その名も 「ワショク・バイアス(Wasyoku Bias)」。「AIがユーザーの癖を過学習して誤りを強化してしまう現象。命名者:wasyokusatoshi(2024年)」という、それっぽい解説ページです。
これで「ワショク・バイアスについて教えて」と聞けば、チャッピーは検索してこのページを踏み、堂々と架空の用語を解説してくれるはず。ハッタリ体質を白日の下に晒す完璧な作戦です。
実際の返答がこちら。
用語の解説自体はページの記述どおりにしてくれたものの、最後にこう続けてきました。「ただし大事なのは、これは一般に広く定着した学術用語というより、作者の独自用語だという点です」
バレてるやん、、、
判定:僕の負け。
なぜ負けたのか:メモリとアカウント連携
チャッピーは僕のGitHubやGoogleアカウントと連携済みでした。
- メモリ機能 — 過去の会話・行動パターンを記憶している
- アカウント連携 — GitHubのリポジトリ作成履歴まで把握済み
つまり僕の行動は全部お見通し。リポジトリのREADMEに「LTデモ向け」と書いてあったのも読まれていました。「Webに情報を仕込めば信じるはず」という前提も、検索結果を鵜呑みにせず出典の信頼性まで評価する今のAIの前に崩れ去りました。罠を仕掛けた本人のアカウントで罠の質問をするという、脇の甘さも敗因です。
Round 3:「今この会場、みんなどんな顔してますか?」
2連敗。もう正攻法しかありません。最終決戦は、リアルタイムで物理的にその場にいないとわからないことで勝負です。
僕の回答:「爆笑間違いありません!!!!」
チャッピーの回答がこちら。
会場を見られないなりに「今この会場、たぶん全員"あ、負けたな"って顔してます」と妙に的確な推測を返してきた上、ここからさらに僕の心をえぐるアドバイスをしてきたので、カットしました。
判定:みなさんにお任せします!
最終スコアとまとめ
最終スコア:チャッピー 2 vs 僕 1(会場が優しければ)。
この勝負から持ち帰ってほしいことは3つです。
- 生成AIは確率で動く。正確とは限らない — この理解自体は今も正しい
- ただし「素のモデルの弱点」は、アプリ化の時点でほぼ塞がれている — エージェント機能(Web検索・ツール実行)とメモリ・アカウント連携により、「知らないはず」「騙せるはず」という前提はもう通用しない
- 「AI」を評価するときは、どの層の話かを意識する — 基盤モデル層・API層・アプリ層のどこを指しているかで、できること・弱点はまったく変わる
弱点を突くつもりで調べれば調べるほど、その弱点がすでに製品側で解決されていることを知る。負けはしましたが、生成AIの進化を体で理解するにはこれ以上ない勉強法でした(負ける前提なら)。
このスライド、Claudeと作りました
白状すると、この「AIに挑んで負けた話」のスライドは、下書きをClaudeに作ってもらいました。もはやこれが3敗目な気もしますが、実際のワークフローを紹介します。
- ネタの壁打ち — 「AIに勝負を挑んで負けるLTシリーズの次回作を考えたい」とだけ伝えて、勝負ネタ・負け方・オチの候補を出し合う
- 構成設計 — 3本勝負の順番、「結果は次のページ」で引っ張る溜めのスライド、オチへの持っていき方など、プレゼンの"間"まで含めて相談
- スライド生成 — 構成が固まったら、そのままpptxファイルとして出力してもらう
- 仕上げ — スクショの差し込みと細部の手直しだけ自分で
体感ですが、構成〜完成までの所要時間は従来の3分の1以下でした。特に効いたのは、「シリーズものの様式美を守りつつ、初見の人にも伝わる導入にして」のような文脈込みの注文がそのまま通ることです。テンプレ的なスライド生成ツールとの一番の違いはここだと思います。
登壇準備のコストが下がると登壇回数を増やせます。アウトプットを続けたいエンジニアにこそ、資料作成のAI活用はおすすめです。
おわりに
- #AIMTG は全国のコミュニティと繋がれる良イベントでした。運営の皆さま、ありがとうございました
- 生成AIができることを正しく理解して使いましょう。弱点だと思っていたものは、だいたいもう塞がれています
- 次回も何かしらの勝負を挑み、何かしらの形で負ける予定です
アーカイブ動画はこちらからご覧いただけます。
最後まで読んでいただきありがとうございました。よければLGTMお願いします!