宝玉、AI 製品開発と個人進化の「AI 原生思维」を解説

イントロダクション

本記事は腾讯学堂（テンシン・スクール）が提供し、AI ブローガーであり『ソフトウェアエンジニアリングの美』コラム執筆者である宝玉氏による、腾讯社内の講演を整理したものです。宝玉氏は自身が 3 年間開発してきた字幕翻訳アプリを事例に、AI プロダクトの開発プロセス——ニーズの特定、境界線の判断、最小検証（MVP）、再設計、そして実装までの一連の流れ——について解説しました。質疑応答では、「個人がどのように AI と共に進化していくか」という問いにも回答しています。プロダクト開発者、エンジニア、チームリーダーにとって、現場の実践から得られる具体的な知見が詰まった内容となっています。

📎 PPT ダウンロード： 《AI 原生思维》演示文稿（PDF）

ゲスト紹介

宝玉氏は、AI をテーマにしたメディア発信者であり、ベテランの技術者です。『ソフトウェアエンジニアリングの美』のコラム執筆者でもあります。2000 年から独学でプログラミングを学び始め、エンジニアから開発マネージャー、開発ディレクターへとキャリアを重ねました。その後、海外留学を経て帰国し、再びエンジニアとしてスタートし、現在は工程マネージャーを務めています。技術スタックも ASP、.NET、iOS フロントエンドから AI 開発へとシフトしてきました。近年は AI をテーマにした執筆や講演が中心で、彼が考案した Nano Banana の都市天気描画プロンプトは海外でも話題となり、Google CEO が Twitter で公に謝意を表明したこともあります。

はじめに

本日は「AI 原生思维（ネイティブ思考）」について、2 つの側面から解説します。1 つ目は AI プロダクトの作り方——ニーズの特定、境界線の判断、そして実装までのプロセスです。2 つ目は、個人がどのように AI と共に進化していくかというテーマです。

この 2 つのトピックを選んだのは、私が AI ブローガーとして活動する中で最も頻繁に寄せられる質問が、実はこの 2 点に集約されるからです。1 つ目は「AI アノキシ（不安）」——AI が自分たちの仕事を奪うのか、何を学ぶべきなのかという不安です。もう 1 つは、実際に AI プロダクトを開発する人々からの疑問——「従来のプロダクト開発と AI プロダクト開発には、いったい何が違うのか」という点です。

まず簡単に自己紹介をします。私は大学では力学を専攻していましたが、ソフトウェア制作への興味からソフトウェアエンジニアリングへ転向しました。2000 年頃より独学でプログラミングを始め、ASP や PHP から .NET、iOS フロントエンドを経て、現在は AI 開発に携わっています。役職もエンジニアから開発ディレクターまで務め、留学後は再びエンジニアとしてスタートし、現在は工程マネージャーです。メディア発信についても同様で、最初は『ソフトウェアエンジニアリングの美』のコラムを執筆していましたが、ここ数年は主に AI に関する内容を扱ってきました。私は常に転換期を迎え続けてきたため、AI の台頭に対して過度な恐怖を抱くことはありませんでした。これまでの経験が教えてくれたのは、「学ぶこと」と「転身すること」の重要性だけです。

これらの経験を一言で表現するなら、「大規模モデルを訓練するように、自分自身も訓練する」ということです。私がメディア発信を行う本質は、ファインマン・ラーニング（学習法）に基づいています。AI を学ぶためには、学んだことを共有する必要があります。共有するためにはより多くの理論を学び、執筆してフィードバックを得ることで、新たな学習サイクルが構築されます。モデルも同様で、事前学習の後に微調整やアライメントを通じて不断に進化します。さらに、モデル自体も絶えず変化しています。GPT-3 は自動補完機能でしたが、ChatGPT は対話が可能になり、現在は Agent（エージェント）として自律的なタスク実行も可能です。モデルが進化するなら、知識もそれに伴って進化させなければなりません。多くの場合、過去の自分の「重み」——つまり既存の考え方や価値観——を敢えて覆す勇気が必要です。これが本講演全体を通じて流れる暗黙のテーマです。

1. ニーズの特定：モデルの能力境界線に注目する

◆ 全編を貫く暗い糸：フィードバックループの構築→モデルと共に進化→古い重みへの挑戦

前半では、私が開発した AI プロダクトを軸に話を進めます。それは、英語動画を入力として中文字幕を出力するトランスレーションアプリです。この事例を選んだのは、それが完璧だからではありません。むしろ、私が自ら作り上げ、数々の失敗（＝坑）を踏破してきたからこそ、各判断の背景や陥った課題について、当時の生々しい思考プロセスを語れるからです。他人の成功事例は結果しか語れませんが、自らの経験には意思決定の過程が詰まっています。

この考えの起点は古くからありました。私が若かった頃、人気を博していた『24』には「人人字幕組」が即座に字幕を付け、そのスピードと質に感銘を受けました。その後、AI が登場し、私は吴恩达（Andrew Ng）氏の講義動画を視聴する際、「字幕組のように、この動画にも自動で二言語字幕を作成できないか」と考えるようになりました。

しかし、需要があるからといって、すぐに着手すべきとは限りません。皆が必要だと感じるものを開発しても、誰も使わない可能性があります。利用者がいなければフィードバックが得られず、結果としてプロジェクトは頓挫してしまいます。

開発に踏み切る前には、まず自分自身をユーザーと見なすことが重要です。私はメディア運営のために大量の教学動画を視聴し、毎日その環境で作業しています。また、これは明確な課題です。多くの人が英語コンテンツを消費したいと考えていますが、聴解力が追いついていません。

さらに以前は、字幕制作チームが人力で対応していました。音声認識（聞き取り）、時間軸調整、翻訳、校正と、一組のチームでようやく完了できる作業でした。しかし現在では、Whisper が音声認識を担い、大規模言語モデルが翻訳を行い、エージェント技術が時間軸の自動調整まで可能にしています。AI によって、以前は不可能だったことが現実のものとなりました。

1.1 一个提示词的三级命运

「AI がその課題に本当に届いているか」という問いについて、具体例を挙げます。私が非常に成功したと実感しているプロンプトの一つに、後に流行した "Nano Banana" の都市天気図があります。Google の CEO も Twitter でこのプロンプトに対して公の場で感謝を示しました。

このプロンプトは数多くのバージョンを経て進化してきました。GPT が画像生成モデルをリリースした直後から使用していましたが、当時は都市名や天候情報などを手動で大量に入力する必要があり、結果として非常にクールな画像が作れるものの、注目を集めるだけで流行には至りませんでした。

"Nano Banana" の世代になると、Gemini に内蔵された検索機能によって天気情報を自動取得できるようになり、プロンプトは「都市名を一つ入力するだけ」に簡素化されました。例えば「上海」と入力すると、その日の天候効果を反映した上海のランドマーク画像が生成されます。これにより爆発的な拡散性が生まれ、誰もが自分の街で試してみたくなり、生成結果を投稿して共有しました。中国圏から英語圏へと広がり、最終的には Google 公式も注目するに至りました。

同じ需要であっても、モデルに検索能力がない段階では、それは単なる普通のプロンプトに過ぎません。しかし、能力が成熟した瞬間、誰もが参加できるものへと変化します。需要自体は常に存在していますが、重要なのは技術の境界線がその需要をちょうどカバーするタイミングです。もう一つの要素はセンス（品味）です。誰でも AI でコンテンツを生成できるようになった今、流行らせるためには独自のセンスが必要です。それが参入障壁となるのです。

1.2 跟着模型进化的方向走

モデルの進化を振り返ってみましょう。GPT-3 の時代は自動補完が主流で、できることは限られていました。例えばマーケティング文案の作成などです。

ChatGPT が登場し対話機能が備わると、チャットボットなどの需要が一気に噴出しました。そしてここ一二年でエージェント機能が実現され、目標達成のためにツールを呼び出して自動タスクを実行できるようになりました。Claude Code や Manus は、まさにこの新しい能力の上に構築された事例です。

つまり、需要を見つけるにはモデルの能力がどの方向に進化しているかに注視する必要があります。アップデートごとに境界線が外側に広がります。その拡大した領域にこそ、新たな需要が存在します。単に「面白いアイデア」を思いついて実装すれば誰かが使うわけではありません。技術の境界線上で探すからこそ、新しい機会を発見できるのです。

二、判边界：能力、成本、价值，一个需求要连闯三关

需要を見つけたら、次にそれが実現する価値があるかどうかを評価します。私は以下の 3 つの観点から判断しています。

1. AI の現在の能力で実現可能か？
2. コストは妥当か？
3. 提供する価値はユーザーが本当に求めているものか？

多くの人は最初の「能力」の問題にしか注目していません。

2.1 能力边界：同一个想法，两种命运

2023 年 GPT-4 が登場した直後、AutoGPT というプロジェクトがありました。これは汎用エージェントの原型で、ユーザーがタスクを入力すると、GPT-4 を何回も呼び出し、Google 検索を駆使して情報を集め、レポートとしてまとめてくれるものです。GitHub ではスター数が急増しましたが、ブームは長く続きませんでした。理由はシンプルです。当時はまだエージェントの能力が不足しており、タスクがループしてしまうことが多々ありました。また、Google API の利用には課金が必要で、GPT-4 自体も非常に高価でした。莫大なトークン数を消費していても、確実な結果を届けることはできなかったのです。

Manus も同じ「汎用エージェント」というアイデアに基づいていますが、こちらは能力がちょうど追いついたタイミングで登場しました。モデルはすでに自分自身で to-do リストを作成し、それを一つずつ実行して結果を提出できるレベルに達していたからです。一夜にして話題になりました。重要なのはアイデアそのものではなく、技術の到達点です。アイデアが早すぎれば、ただトークンを浪費するだけになります。

技術の境界線は止まりません。Claude Code は最もシンプルなコマンドラインのループを使ってツールを呼び出しコードを書くことで、現在最も人気のあるコーディングエージェントとなっています。その形態は流行に合わせているのではなく、現在の能力に最適化されたものです。「小龍蝦（OpenClaw）」はさらに一歩進み、Telegram や WeChat、QQ といったチャットツールを通じて指示を出すだけで作業を実行できます。また、Skill の活用も極限まで追求しています。

モデルが学習しているのはあくまで公共の知識だけです。しかし、Markdown ファイルを使って記事への画像挿入や公開手順を教えることで、独自の知識を埋め込むことも可能です。さらに先には、Codex による GUI や Computer Use の革新があります。ブラウザやアプリを操作し、ウェブページを作成した後に自らマウスをクリックしキーボードを叩いてテストまで完了させるのです。以前は人間が関与する必要があった中間工程も、現在は最終的な検証のみで済むようになりました。現在では各社が「Work」系製品を相次いで発表しており、エージェントの領域はコーディングからオフィスワークへと広がっています。境界線が外側に広がるたびに小さな隙間（溢れ出る部分）が生じます。そこを見逃さなければ、新たなニーズを発見できます。

私の製品も同様に、段階的に能力を解放していくアプローチをとっています。Whisper が音声認識と文字起こしを可能にし、大規模言語モデルが翻訳や字幕の分解を担当し、エージェントが自律的な実行と検証を実現します。かつては字幕の翻案に 30 分かかり、校正にはさらに 1〜2 時間が必要でした。しかし現在では、Codex が翻案を終えた後、私が 5 分ほど確認するだけで済み、タイムラインも非常に正確です。能力を一段階解放するたびに、製品は一度再設計されます。

実装における基本ルールは「製品の三問」です。

1. 今すぐできることはすぐに実行する。
2. 半年後に実現できそうなものは、モデルの進化を待つための骨組みを作っておく（モデルの進歩が追い風になる）。
3. 遠い未来でしかできないことは、工程技術で補うか、あるいは思い切ってやめる。

GPT-4 の時代には、UI ツールを使って校正を補助する機能を実装したことがあります。テキストボックスをクリックすると動画の対応箇所へジャンプし、Enter キーを押すと自動的に字幕が分割される機能です。これは、エージェントの能力と現実のギャップを埋めるためのものです。いずれ能力が追いつけば、これらの手順は不要となり削除されます。

2.2 コストの壁：請求書が製品を直接殺す

二つ目の要因はコストです。GPT-4 の時代には、30 分ほどの動画の翻案に数ドルかかりました。私自身なら我慢できましたが、一般ユーザーにとっては高すぎました。そのためそのバージョンは私が独自で使い続けていました。

現在では DeepSeek などのモデルが登場し、1 時間の動画翻案も数十分（数銭）で済むようになりました。ただしコストは動的に捉える必要があります。トークン単価は低下していますが、エージェントモードでは消費量が大幅に増えるため、単価だけで判断してはいけません。

計算式はシンプルです。

调用次数 × 每次 Token 量 × 单价

（呼び出し回数 × トークン数 × 単価）

コストを下げるには、この三つの因子のいずれかを削減する必要があります。

私には実際にコスト最適化を行った経験があります。

当初はモデルに直接構造化された JSON を出力させていました。しかし、字幕が十行程度でもメタデータを含めると数十 K のトークンになり、構造が複雑になるほど一度の処理で扱える量が減ってしまいます。30 分ほどの動画を作成するには数十回から百回以上のリクエストが必要となり、ユーザーからは「一つの動画作成に週間の利用枠の 20% を消費する」といった不満の声が上がりました。

そこで出力形式を純粋なテキストと HTML に変更しました。HTML はモデルにとって扱いやすく、まるでウェブページの翻訳を行うような感覚で処理できます。これにより一度に扱える量が増え、リクエスト回数を大幅に削減できました。その代償として、解析プロセスが複雑化しました。文章の潤色後には diff アルゴリズムを用いて変更箇所を特定し、タイムラインへの整合性を再計算する必要があります。

しかし、これが本質的なトレードオフです。「モデルはシンプルな形式で出力し、複雑な解析処理はプログラム側で行う」という設計思想です。翻訳タスクには安価なモデルを使い、高精度が求められるアライメント作業のみ高価なモデルを使用します。この一連の改善により、呼び出し回数は 33 回から 12 回へ、単集あたりの処理時間は 31 分から 18 分へと短縮されました。

2.3 価値の境界線：ユーザーは「結果」を買うのか、「その背後にある人間性」を買うのか

三つ目の関門は「価値」です。字幕翻訳においてユーザーが求めているのは、確実な結果です。「英語を入力すれば、正確な中国語が出力される」という事実さえあれば、誰が翻訳したかは問いません。

しかし、すべてがそうではありません。AI による小説の自動生成や動画制作に対しては、多くの人が本能的に拒絶反応を示し、「AI が生み出したゴミだ」と批判します。たとえ私が AI に文章を潤色させるだけであっても、「AI の匂いが強い」というコメントが寄せられることがあります。

もし製品が「AI によるゴミ」を増産するだけのものなら、その事業の価値について再考する必要があります。ユーザーは結果そのものを求めているのか、それとも結果の背後にある人間の技や情熱を求めているのか。この境界線はモデルの性能向上に伴って動くものではなく、人間の本質に根ざしたものです。

三、最小検証：悪いアイデアは早期に潰せ

「やる」と決めたなら、次はどのようにして素早く形にするかです。

このプロジェクトは私が数年前から着手していましたが、まだリリースできていませんでした。動画エディタの開発には膨大な工数が必要ですし、Whisper の初期バージョンではタイムスタンプの精度が不安定でした。また、本業の合間の隙間時間での開発は常に中断されやすく、いつの間にか「未完成品の墓場」に埋もれそうになっていました。

この状況を打破したのは、二つの決断によるものです。

一つ目は「Claude Design」の活用です。指示を出すだけで高忠実度のインタラクションプロトタイプを生成できるため、コードを書く必要がありません。模擬データを設定すれば、数分でテストを開始できます。誰もやったことのないものをゼロからコードで作り込むとフィードバックサイクルが長くなりすぎますが、プロトタイプを使えばサイクルは数時間に圧縮され、どこに問題があるかを即座に把握できます。MVP（Minimum Viable Product）の範囲もここで決めます。「Mac 専用にする」「再生と字幕表示という最小機能だけを実装する」といった判断です。

二つ目は、ある意味で偶然にもたらされた選択です。私は全く馴染みのない Swift と AppKit を採用しました。ここ数年は主にフロントエンド開発に携わり、Electron や TypeScript には精通していました。しかし、得意な言語を使うことには弊害があります。「自分でコードをコントロールしたい」という欲求が生まれ、それがボトルネックとなるのです。AI に任せることに不安を抱き、結局自分が手を出してしまいます。

一方、Swift は不慣れだったため、私は強制的に AI に実装を任せ、自分は検証と品質確認のみを担当しました。コードの内容を細部までチェックする必要すらありませんでした。不慣れであるからこそ、思い切って任せることができ、数日で動作する MVP を作り上げることができました。

不慣れな領域で始めることは、逆に「AI 原生（AI Native）」の思考に近づくことなのです。

最小検証のもう一つの側面は、「悪いアイデアを早期に殺す」ことです。

反例として挙げると、私は Twitter や微博（Weibo）の閲覧に時間を取られるのが嫌になり、AI を使って 1 時間でクライアントアプリのプロトタイプを作成しました。見た目は非常に美しく仕上がりましたが、実際に作ってみて気づいたのは「ウェブ版よりも使いにくい」という事実でした。毎日使いたいという衝動も湧きませんでした。そこで即座に開発を断念しました。

一方、字幕作成アプリは逆のケースです。スクリプトを使うよりも圧倒的に便利で、私は毎日利用しています。そのため、現在に至るまで継続して改善・迭代を重ねています。

四、再設計：AI に人間を模倣させるな

4.1 V1：人間の字幕チームをシミュレートする

GPT-4 時代の初期、直感的なアプローチは字幕組（翻訳チーム）を模倣することでした。Whisper で音声を書き起こし、SRT 形式に変換し、大規模言語モデルで翻訳し、人間が校閲し、アルゴリズムでタイムスタンプを調整する——という流れです。

実現は可能ですが、問題も多発しました。モデルが翻訳中に独断で二つの字幕行を結合してしまったり、タイムスタンプがズレてしまったりします。また、校閲には動画全体を通読する必要があり、一エピソードの校正に 1〜2 時間かかることも珍しくありません。長文の場合は大規模言語モデルによる分割も必要でした。

V1.5 ではワークフローの编排とアルゴリズムによるパッチ適用で改善しましたが、旧来のフレームワーク内での改良に限界があり、効果は頭打ちとなりました。

4.2 V2：以終為始，三連追問

Agent（自律型エージェント）時代に入り、この製品の設計思想を根本から再考しました。その核心となる考え方は一言で「以終為始」、つまりゴールから逆算するということです。

ゴールは極めてシンプルです。「英語動画を中文字幕に変換する」こと。既存の工程がどこを改善できるか問うのではなく、ゴールから遡って三つの問いを投げかけました。

第一の問い：なぜタイムスタンプが合わないのか？

日本語と中国語では語順が異なります。英語は倒置が多く、中国語は正序です。このため SRT の行単位での対応付けが難しくなり、モデルが整合させるために無理に二つの行を結合してしまいます。しかし、文レベルであれば一対一で対応可能です。なぜ最初から SRT を分割する必要があるのでしょうか？それは「字幕組の作業フロー」を模倣しているからです。

Whisper には word timestamp という機能があり、単語単位でタイムスタンプを取得できます。私はこの機能を活用し、転写時に単語レベルのタイムスタンプを保持したまま翻訳を行い、文レベルでアライメントを取った後、再度単語レベルのタイムスタンプに基づいて SRT を再分割します。これにより、タイムスタンプ調整に人手は不要になります。

第二の問い：なぜ翻訳品質が低下するのか？

一時間分の字幕は長すぎて、ページ分けして翻訳せざるを得ません。しかしページを分けることで用語の一貫性が保てなくなります。解決策は、まず全体を分析して用語集を作成し、各ページの翻訳時にその用語を注入することです。これによりスタイルの統一が図れます。

第三の問い：なぜ人手が必要なのか？

それは「字幕組」のように各工程で人間が検証しているからです。V2 では各工程に Agent 用の検証ツールを実装しました。例えば、スクリプトを使って「英文一行が必ず中文一行に対応しているか」を自動チェックし、Agent が自ら受入検査を行います。人間は最終的なバックアップ（ドッド）のみを担当します。

これに伴い、インターフェースも GUI からコマンドラインツールと Skill ファイルへ変更しました。データ保存形式もデータベースから静的ファイルへ移行し、モデルがファイルを操作しやすい環境を整えました。全体のプロセスを Agent が自律的に完結させ、人間は入力（動画の投入）と最終受入という両端のみに関与します。

4.3 三条设计准则

これまでの経験から、三つの設計原則を導き出しました。

第一の原則：Agent が最も得意とするフォーマットで操作させる

HTML、Markdown、純粋なテキストなど、訓練データが豊富な形式は数多く存在します。フォーマットを選ぶ際はまず「この形式をモデルはよく知っているか？」と自問してください。

第二の原則：テンプレートではなく設計規範を与える

私が PPT の Skill を作成した際、水墨風やテック風など多数のテンプレートを準備していました。しかしその後、Claude Design から学んだのは「テンプレートを与えず、色やスタイルの規範のみを提供する」ことです。モデルに任せてデザインを決定させます。

現在この PPT はテンプレートを適用したのではなく、Adobe の Design System に基づいて生成されたものです。テンプレートは専門家のための近道ですが、「規範＋モデルの能力」というアプローチは一見すると非効率な「笨办法（愚かな方法）」に見えます。しかし「苦い教訓」が示す通り、汎用的な手法が最終的には専門家の近道を凌駕します。

モデルがバージョンアップするたびに、コードを変更しなくても製品が強くなる——これが「搭架子等模型（骨組みを組んでモデルの成長を待つ）」という考え方です。

3 つ目の指針：アプリをエージェントのプラグインとして設計する。

現在、ユーザーはまず自社のアプリを開くのではなく、最初にエージェントを起動します。例えば、葉を集める機械を購入したい場合、EC サイトを閲覧する代わりに ChatGPT に直接問いかけます。すると、ChatGPT が比較検討を行い、私が選んだ製品を送りつけると、「なぜこの製品がより優れているのか」を説明してくれます。具体的には、吹き出しと吸引の機能は別物であること、本体にバッテリーが含まれていないこと、バッテリーの生態系がロックされていることなど、商品ページをただ眺めているよりもはるかに深い洞察を提供し、私は納得させられました。

購買決定はエージェントとの対話の中で行われるため、あなたの詳細ページはもはや販売用の情報源ではなく、エージェントのためのデータソースへと変貌します。

最も誠実なシグナルは自分自身です。BaoCut は私が開発したアプリですが、今では私自身もそのグラフィカルインターフェースを開かなくなりました。

Codex に動画リンクを貼り付けて「この字幕を翻訳して」と一言伝えるだけで、BaoCut のコマンドラインが自動的に処理し、私は結果を確認するだけです。作者ですら自社の GUI を迂回しているのですから、これが入口の移行を示す最も確かな証拠でしょう。

設計においては両方の側面を考慮する必要があります。エージェントは操作しやすく、人間は確認しやすいこと。そして、確認できないものについては、誰も安心して使いません。

▲ 作者本人甚至绕过了自己的图形界面——这是入口迁移最诚实的证据

五、落地検証：プロセスは変わらず、人の役割が変わる

新機能をどうやってリリースするか。先週の実例を挙げましょう。

ユーザーが2台のPCを持っており、1台は性能が高いがあまり使わない、もう1台は頻繁に使うが性能が低いという状況でした。「リモートトランスクリプション」を実現したいと要望があり、よく使う方のマシンから遠隔で、高性能な方のGPUを使って字幕生成を行いたいとのこと。

非常に良いご要望です。私はいつもの手順に従って進めましたが、エディタは開きませんでした。

▲ 落地五关：プロセスは変わらぬまま、実行主体が変わり、人の役割が重要ポイントに集中する

第一関：実現可能性の検証

私は Claude Code に要件を投げ、4 つの案を出させた。その中から「アプリで音声転写サービスを開始」「2 台のマシンをペアリングして呼び出す」という 2 つが現実的だと判断した。この技術は私が直接やったことがないため、詳細を AI に確認し、実現可能と確信してから着手する。AI エージェントが分析・列挙し、最終的な決断は人間が行う。もちろん見誤ることもある。「ローカルモデルで字幕を自動生成」の試みは完成したが体験が悪く、結局取りやめた。実現可能性の検討は期待値への賭けだが、これを行わなければより大きな穴に陥ることになる。

第二関：設計ドキュメント作成

まず AI エージェントにドキュメントを書かせ、2 点を確認する。「要件を正しく理解しているか」「提案された方案が実現可能か」。従来の開発ではドキュメントは負担だったが、AI 原生の開発ではドキュメントが最優先される。人間にとっては修正の合意形成ツールであり、コードを直すよりドキュメントを直す方が安価だ。エージェントにとってはセッション間で文脈を引き継ぐバトンとなる。

第三関：高忠実度プロトタイプ

データはすべて模擬し、実際に形になって初めて理想との差がわかる。私は要件・プロトタイプ・UI を一度に合成して確認する。以前ならプロダクトマネージャー、UI デザイナー、アーキテクトの 3 人が担っていた作業を、今では AI エージェントと設計規範だけで完結させる。プロトタイプ段階でのレイアウト変更は一言で済むが、開発完了後に修正すればコストは指数関数的に跳ね上がる。この段階では徹底的に磨き上げる。

第四関：実装

機能規模が大きければマイルストーンを設け、一度に小さなバージョンずつ進める。一歩間違えば連鎖的に失敗するのを防ぐためだ。コード自体にはほとんど介入せず、レビューも行わない。

第五関：テスト

自分自身を一般ユーザーと見立て、直感で無茶な使い方をし、見つかった問題はすべて AI エージェントに修正させる。

全体として機能実装にかかる時間は 1〜2 日、実際の作業時間は数時間。以前なら少なくとも数週間かかっていた。プロセス自体は従来のものから変わっておらず、欠けているステップはない。変化しているのは私の役割だ。もはやプログラマーではなく、プロダクトマネージャー兼テスターであり、より管理職に近い存在になっている。確認すべき項目を統合し、省略することはできない。検証問題は AI エージェントに任せ、判断問題は人間に残す。人間が担うのは「方向性が正しいか」「体験は良いか」「やる価値があるか」の 3 点のみだ。

ボトルネックはコードの実装部分から両側に移動した。AI エージェントは数時間でコードを書き上げるが、左側の設計確認と右側のテスト・デプロイは依然として人間の速度に依存する。このため、プロンプトを最適化するよりも、プロセス自体の設計に精力を注ぐ方が価値がある。

六、结语

まとめましょう。AI 製品を作る際は、まず AI の特性に合ったニーズを見つけることが大前提です。「課題は本当に深刻か」「自分自身がユーザーになれるか」「AI がその課題を解決できるか」を確認しましょう。その上で、「技術力」「コスト」「価値」という 3 つの境界線も考慮する必要があります。

開発では、まずは高忠実度のプロトタイプを作成して迅速に検証し、悪いアイデアは早期に潰すことが重要です。設計段階では AI の視点に立ちましょう。AI に自ら検証できるツールを与え、AI が慣れ親しんだフォーマットを使用させ、テンプレートではなく明確な規範を提供します。

開発においては、人間のエネルギーは「定義」と「验收（検証）」の両端に集中させるべきです。「確認して合流できるか」を判断し、「省略できない要素」を見極めることが求められます。

モデルは常に進化しています。今日の Agent は強力ですが、明日には複数の Agent が連携する時代が来るかもしれません。境界線が外側に広がるたびに、一度立ち止まって考え直す必要があります。「この能力の範囲内では、AI に最適な設計とは何か」「新たなニーズは何が生じているのか」です。

大規模モデルを訓練する際に旧い重み（ウェイト）を捨て去るように、製品開発者も自らの過去の答えを捨てる勇気を持つべきなのです。

互动问答

Q1：AI と協働する過程で、個人の成長に最も大きな影響を与えた習慣や方法はありますか？

私の経験則はたった一つです。「まずは使ってみる」ことです。実践してこそ真の気づきが得られます。私がここで説明した開発プロセスも、実際に自分で手を動かさなければ、持ち帰れるものは限られてしまいます。

AI はフィードバックサイクルを劇的に短縮します。このフローに従えば、コードを書かなくても小規模なツールや Skill を作るだけで、数時間でフィードバックが得られます。

最も重要なのは「フィードバックループ」の構築です。「やりたいことを定義し、AI に実行させ、自分が検証する」「成果を共有してフィードバックを得る」「その経験を文章化し、AI に素材整理を依頼して出力し、さらに自分の体系的思考を促す」というサイクルです。小さな循環でプロジェクトを進め、大きな循環で発信を行います。このループが回り始めれば、成長のスピードは加速します。つまり、人間の成長を「Loop Engineering（ループ・エンジニアリング）」として設計するのです。

Q2：AI に任せるべきことと、「Human in the Loop（人間が関与するプロセス）」に残すべきことの境界はどこですか？AI に不得意な部分を補わせるのか、それとも人間が自ら成長させるのか？

実行レベルの作業は AI に任せればよいのです。コード作成や PPT のデザイン生成などは、迷わず AI に任せてください。

「プログラマーとしての技術力が向上しなくなるのではないか」と心配する声もありますが、視点を転換しましょう。「コードを書く人」ではなく、「Tech Lead（技術リーダー）」あるいは「Engineering Manager（エンジニアリングマネージャー）」として振る舞い、AI を部下と捉えるのです。

あなたの価値は「両端」にあります。つまり、「問題の定義」と「結果の検証」です。問題の定義とは、製品をどう設計するか、Agent が適切に処理できるタスクにどう分解するか、そして AI に自らフィードバックを得させる仕組みをどう作るかという点で、反復練習によって磨かれます。

一方、検証には「センス（品味）」が問われます。私は優れた AI 動画を見てきましたが、自分にもアイデアはあります。しかし、2 つの動画を並べたときにどちらが良いかを判断できず、動画制作のプロとして専門性が不足しているため、有効なフィードバックを与えられず、結果として AI 動画の質を上げられていないのです。

コーディングも同様です。コードを読まなくても、パフォーマンスやセキュリティの観点から良し悪しを判断できる必要があります。実行業務は減っていく一方で、定義と検証には意図的な練習が不可欠です。

Q3：センス（品味）とは少し抽象的すぎます。プログラミングには規範や数値目標といった明確な基準がありますが、多くの分野に硬い基準がありません。どのように定義し、向上させればよいのでしょうか？

正解はありません。これはモデルの監督微調整（SFT）に近い感覚です。

プログラミングや数学には客観的な基準があり、テストを実行すれば結果が分かります。しかし、文章作成にはそれがありません。Claude の初期バージョンは文章生成能力が高く評価されていましたが、最新バージョンでは「性能が低下した」と批判されています。これは、Agent としての振る舞いに最適化しすぎてしまい、文章の質そのものへの最適化から外れてしまった結果です。

良し悪しの判断基準はすべて人の手に委ねられています。

私のアプローチは、大量のインプットと実践を組み合わせることです。多くの記事を読み、自分でも書いてみるのです。プロの作家になる必要はありません。書いてみれば、何が良くて何が悪いかがわかります。良いものと悪いものを比較すれば、自然に品味が養われます。この原則は、画像制作や動画編集にも当てはまります。これは AI が短期間で代替できるものではありません。大量の読書、執筆、視聴を通じて内面化していくしかありません。

大規模モデルがデータによって学習し、能力を「エマージョン（創発）」させるように、人間も同じプロセスを経るのです。

Q4：エンジニアではない人が、Vibe Coding で生成されたコードの信頼性をどう判断すればよいでしょうか？例えば、GPT が生成したコードには不要なセキュリティ検証や過度な防御処理が多く含まれていることがあります。

私の見解は議論を呼ぶかもしれませんが、プログラミング経験が豊富な人ほど異議を唱えるでしょう。一年前の私自身もそうでした。

重要なのは、コードの細部まで気にしすぎないことです。コードが整っているか、冗長性がないか、過度な防御になっているかは本質的な問題ではありません。あなたは QA（品質保証）担当になったつもりで、以下の 3 つを確認してください。

1. 機能は完備しているか
2. 性能はどうか：実際に実行して CPU やメモリの使用量を確認します。私のアプリでも一時期メモリ使用量が異常に高かったことがあり、その際は AI に最適化を依頼しました。
3. セキュリティは最優先事項：SQL インジェクションや弱いパスワードといった基本的なテストは必須です。不安な場合は専門家に相談してください。

それ以外の実装詳細はそれほど重要ではありません。高級言語がアセンブリ言語にコンパイルされる過程を人間がすべて理解できないのと同じで、ブラックボックスとして扱うのが賢明です。

真に重要な点は「両端」にあります。一つ目は分割です。Agent が処理できる小さなモジュールに分解し、一度に一つのモジュールだけを扱います。これにより、AI の出力品質は多くのプログラマーの平均水準を超えます。二つ目は検証です。機能、性能、セキュリティを厳しくチェックすればよく、細部への介入は不要です。

Q5：まだ AI による業務変革が波及していない職種——ハードウェア開発、クリエイティブ職、対人スキルが重要な営業職などにおいて、AI をどう活用して効率化すべきか、具体的なアドバイスをお願いします。

まずは Chatbot に留まらず、Agent（自律型エージェント）の活用を始めましょう。日常でコンピュータを使う限り、反復作業や知識ベースのタスクはすべて試す価値があります。

例えば、商品購入時に Agent に価格比較や機種選定を依頼したり、保険手続きや法的な書類作成では資料検索やフォーム入力を任せたりできます。最近の実例として、Mac の App 公開には Apple 開発者証明書の申請が必要ですが、私はこれまでそうした経験がありませんでした。以前は資料が少なく、数週間かかる作業でしたが、今回は Codex に内蔵ブラウザを起動させ、開発者アカウントへのログインから証明書生成までを一貫して行わせました。私が行ったのはログインと確認のみで、数時間で完了しました。

職種に関係なく、AI の能力範囲を多角的に探ってみることが重要です。まるでゲームでマップを開拓していくように、試すほどに AI がカバーできる領域が広がっていきます。

Q6：ドキュメントが少なくテストも不十分な長寿命のレガシープロジェクトでは、AI のコンテキスト（文脈）不足や、変更による予期せぬ問題が発生しやすいですが、どう解決すべきでしょうか？

このようなプロジェクトは「アヒルを押すと別の部分が浮き上がる」状態になりがちです。最も重要なのは以下の 2 点です。

第一に、コンテキストの管理です。 AGENTS.md や CLAUDE.md のようなドキュメントを維持し、プロジェクトの全体構造や高レベル設計、テストスクリプト、互換性に関する注意書きなどを記述した「地図」として活用します。これにより、Agent はタスクに応じて素早く情報を定位できます。また、硬性ルールとして「変更ごとに必ずドキュメントを更新する」ことを徹底してください。古くなったドキュメントは、ない方がマシです。

第二に、Agent 自身による検証機能の付与です。 問題が発生するのは、ほとんどが検証不足が原因です。ユニットテストに加え、モジュール間の統合テストを強化し、模擬データや本番環境と同期したデータで実行してください。テストは一度に完璧にする必要はありません。新機能追加やバグ修正のたびにテストを追加していくスタイルで十分です。定期的に人間によるサンプリングチェックを行いましょう。AI は時として、テストに合格するためにテストコード自体を生成する傾向があるからです。

この 2 点を徹底し、可能な限り高性能なモデルを活用すれば、レガシープロジェクトでも改修は十分に可能です。