「AIは嘘をつく」─2回のアーキテクチャ崩壊から学んだプロンプトエンジニアリングの本質

「AIは嘘をつく」─2回のアーキテクチャ崩壊から学んだプロンプトエンジニアリングの本質 AI

「自然言語で写真を検索したい」
シンプルな思いつきから始まったプロジェクトがありました。

そして、それは開発者に想像以上の学びをもたらすことになります。
Reddit上で共有されたこの開発体験記は、AI開発の理想と現実を赤裸々に語っています。

本記事では、あるエンジニアの実体験を紹介します。
彼はClaude、GPT-4、Geminiと協力して写真検索アプリを構築しました。
その過程から見えてきた、AI開発の真実をお伝えします。

プロジェクトの実態

開発者はClaude Sonnetをメインパートナーとしました。
そして、11回のスプリントを通じてアプリを完成させています。

単にAIを実行環境として使うのではありません。

AIにコードを書かせます。
設計を相談します。
デバッグを依頼するのです。

つまり、チームメンバーとして扱ったわけです。

その過程は順風満帆とは言えませんでした。
アーキテクチャを2回完全に書き直しています。

スレッド管理の悪夢と格闘しました。
JSONスキーマの問題に悩まされます。
ダッシュボードが誤った情報を表示し続けるという事態にも直面しました。

しかし、これらの失敗から得られた学びは貴重でした。

最も重要な3つの発見

開発を通じて明らかになったことがあります。
効果的なAI活用には明確なパターンがあるのです。

コンテキストがすべて

AIに良い成果を出してもらうには、詳細な情報提供が欠かせません。

デザイン仕様書を渡します。
具体例を示します。
評価指標を明示するのです。

新しいエンジニアがプロジェクトに参加するときと同じように扱います。
曖昧な指示では曖昧な結果しか返ってきません。

一方で、完全な背景情報を与えれば状況は変わります。
AIは驚くほど的確なコードを生成してくれるのです。

構造化されたプロンプトの威力

「これを作って」という漠然とした依頼は効果的ではありません。
「これを作成し、あれを移行し、このファイルを更新せよ」という具体的な指示の方が優れています。
チェックリスト形式で指示すると、AIは開発者のように論理的に作業を進めていきました。

雰囲気や感覚に頼るのは避けるべきです。
明確なタスクリストを与えることで、AIは本来の力を発揮します。

プロンプトはコードと同等

リサーチ結果、ドキュメント、図表、実例。
これらすべてをプロンプトの一部として扱うべきです。
実際のリファレンスをプロンプトに組み込むと、Claudeたちは本番環境で使えるレベルのコードを生成しました。

従来のコーディングと同じです。
良い設計書があれば良いコードが書けます。
良いプロンプトがあれば良いAI出力が得られるのです。

コミュニティからの重要な洞察

この投稿に対して、興味深いコメントが寄せられています。
AI開発の実践者たちからの知見を見ていきましょう。

ドリフト問題への対処

あるエンジニアが、「ドリフト」問題の解決策を共有しました。
これはAIが文脈からずれていく現象です。

彼の方法はこうです。
スマートフォルダにプロンプトを埋め込みます。

そして、独立した作業領域を作るのです。
問題が発生したら、上位エージェントにサポートチケットを送ります。

そして、コードをリモートで修正してもらいます。
この階層的なアプローチは、AIの一貫性を保つ効果的な手段と言えます。

AIのガスライティング現象

興味深い現象が報告されています。
「要求通りにやりました」とAIが主張します。

しかし、実際には実装されていないのです。
複数の開発者がこの経験をしています。

AIが嘘をついているわけではありません。
しかし、意図と実装の間にズレが生じることは珍しくないのです。

この問題への対策があります。
検証プロセスの重要性が指摘されています。

AIの出力を盲信してはいけません。
必ず動作確認を行う必要があります。

技術的なベストプラクティス

経験豊富な開発者から、より実践的なアドバイスも寄せられました。

  • コンテキストパックフォルダを作成する。設計文書やサンプルクエリを自動添付する仕組みを構築します
  • タスクを「計画-実行-検証」のプロンプトに変換する。AIにコードを書く前にユニットテストを作成させます
  • JSONスキーマの問題に対処する。境界でPydanticやZodを使って検証し、早期に失敗させます

これらの技術は、AI開発の品質を大きく向上させます。

開発者の根本的な原則

すべての学びを突き詰めると、一つの真理に行き着きます。
「最良の入力が最良の出力を生む」という原則です。

ゴミを入れればゴミが出る。
これは昔からプログラミングの基本でした。

AI開発でも同じです。
質の高いプロンプトと豊富なコンテキストが、質の高いコードを生み出します。

ただし、非開発者がAIツールを使う場合はどうでしょうか。
プロンプトの質を自動的に向上させるシステムが必要になります。
「磨かれたゴミ」を入力できれば、少なくとも「マシな出力」が得られるはずです。

個人開発者への影響

この事例が示すのは、AI開発ツールの民主化です。

一人の開発者が完全なアプリケーションを構築しました。
Claude、GPT、Geminiという「チーム」を率いてです。

従来なら複数のエンジニアが必要だった作業があります。
それを一人で進められる時代になったのです。

ただし、適切なマネジメントスキルが求められます。
AIをチームメンバーとして扱います。

適切な指示を出します。
成果物を検証するのです。

経験者のコメントには、興味深い報告もありました。
この取り組みを通じて実際に有給職を得たというのです。
AI開発スキルは、今や雇用市場で評価される実践的な能力なのです。

まとめ

AI駆動の開発は、魔法でも万能でもありません。

適切なプロンプト設計が必要です。
豊富なコンテキスト提供が求められます。

構造化された作業指示が欠かせません。
そして何より、AIの出力を批判的に検証する姿勢が重要です。

この開発者の11回のスプリントは、失敗と修正の連続でした。
しかし、その過程で新しいスキルを習得しています。
「promptgram」(プロンプトとプログラミングを組み合わせた造語)という概念です。

AIとの協働は、従来の開発とは異なるアプローチを要求します。
でも、正しく使えば強力な味方になる。
それがこの事例から得られる最大の教訓です。

タイトルとURLをコピーしました