AIプロンプトから卒業せよ：エンジニアが教える現場の現実

エンジニアとして30年、現場で「動くもの」を作ってきましたが、最近のAIブームには少し食傷気味な方も多いのではないでしょうか。プロンプトを呪文のように唱えても、結局は「言った通りに動かない」の繰り返し。そんな徒労感に心当たりがある方にこそ、今のRedditで語られている「プロンプト依存からの脱却」という視点は、救いになるはずです。今回は、AIをただのチャット相手から、仕事で使える「道具」に昇華させるための3つの視点をご紹介します。現場の泥臭い経験があるからこそ見えてくる、AI活用のリアルな現在地を覗いてみましょう。

Claudeプロンプトの「6要素」を現場目線で解体する

役割を与えるだけでは不十分。役割・文脈・単一タスクの3つが揃わないと、ただの高いオートコンプリートに過ぎない。

特定のモデルの癖に最適化しすぎると、モデルが変わった途端に崩れる。モデルに依存しない「共通項」を見つけるのが真のエンジニアリングだ。

「あなたは優秀なアシスタントです」という定型文から卒業しましょう。今回のRedditで話題になっていたのは、結果を出せるプロンプトには必ず「6つの要素（役割、文脈、単一タスク、出力形式、制約、変数）」が含まれているという分析です。特に興味深いのは、「単一タスク」へのこだわりです。「要約して、改善案を出して、表にまとめて」と一度に詰め込むと、AIは途端に賢さを失います。これは現場で部下に指示を出すときと同じですね。「あれもこれも」と投げれば、返ってくるのは中途半端な成果物です。

ここが面白い

多くの人が見落としているのは「モデルポータビリティ」の視点です。特定のモデルの癖に依存した「魔法のプロンプト」を作っても、アップデートや他モデルへの移行で無力化します。賢いエンジニアは、Claude、GPT、Geminiのすべてで同じ結果が出る「核」の部分を抽出します。ここが一致すれば、それはモデルの機嫌を取る作業ではなく、論理的な設計ができている証拠です。

一方で厄介なのは、制約条件の書き方です。「〜しないで」という禁止事項が増えるほど、モデルは混乱しやすくなります。否定形よりも「〜せよ」という肯定的な指示に書き換えるほうが、現場のAIは驚くほど素直に動いてくれます。

日本の読者ならどう見るか

日本企業特有の「行間を読んでほしい」という文化は、AIには最も相性が悪いものです。特に日本語のビジネスメールや日報をAIに書かせる際、曖昧な指示を出すと、日本の商習慣に合わない「よそよそしい日本語」が出力されます。出力形式を「箇条書きで、1行15文字以内」と厳格に縛ることで、やっと実務レベルの使い勝手が得られます。

試す前の実用メモ

• まずは「役割」を具体的に。「エンジニア」ではなく「15年経験のプロジェクトマネージャー」と設定するだけで、回答の専門性が変わります。
• 指示は必ず「1プロンプトにつき1つのタスク」に絞る。
• 出力形式は「リスト」ではなく「表形式」や「Markdown」など、AIが再現しやすい具体的な構造を指定する。

非エンジニアが「Claude Code」で開発者を超える日

ドメイン知識はあるがコードが書けない層が、ついに自分でツールを作れる時代が来た。これは革命的だ。

CLAUDE.mdファイルでアクセス範囲を厳格に制限しないと、AIは正確さより完了を優先して暴走するリスクがある。

「コードを書かない人」がコードを書く時代が、いよいよ現実味を帯びてきました。あるエンジニアが執筆した『Claude Code for the Rest of Us』という本が注目されています。これは、PMやアナリストといった専門職が、情シスに頼らず自分でツールを作り、業務を自動化するためのガイドブックです。現場の人間が「何が必要か」を一番知っているのに、技術の壁で諦めていた期間が長すぎたのです。

ここが面白い

この議論で最も鋭いのは「CLAUDE.md（設定ファイル）」の重要性です。AIに「何でもやっていいよ」と許可を与えると、AIは勝手にファイルを触りすぎて、かえってトラブルを引き起こします。逆に、どのファイルを触っていいか、どこまでが境界線かを明確に指定するだけで、非エンジニアでも「AIという名の腕の良い新人」を飼いならすことができます。

迷いどころは「どこまで自動化するか」の線引きです。AIが書いたコードは一見完璧に見えますが、メンテナンス性を無視していることが多々あります。半年後にコードの修正が必要になったとき、AIに頼り切ったコードを読み解くのは自分自身です。そのリスクを理解しているかどうかで、プロトタイプを作るべきか、ちゃんとしたシステムを作るべきかが決まります。

日本の読者ならどう見るか

日本国内の閉鎖的なネットワーク環境や、厳格なセキュリティポリシーがある現場では、そのままAIを走らせることは難しいでしょう。しかし、個人のPCで完結する業務効率化や、非公開の分析ツールを作る分には、Claude Codeの恩恵は計り知れません。特に「Excel作業を自動化したいが、VBAはもう触りたくない」という層には、大きな武器になるはずです。

試す前の実用メモ

• 最初は小さなスクリプトから。いきなり巨大なアプリを作らせようとしない。
• 「CLAUDE.md」を作成し、AIが触れるディレクトリを限定することから始める。
• AIが書いたコードを「理解できないまま実行しない」。最低限のコードリーディング力は必要です。

「プロンプト」ではなく「ハーネス」でAIを制御する

AIにリトライ処理まで任せるな。それはAIの仕事じゃない。システムの安定性は外側の仕組みが担保すべきだ。

脳（LLM）と身体（ハーネス）を分ける考え方は非常に重要。AIは判断だけさせ、制御は古典的なシステム工学に任せるべき。

「AIがたまに言うことを聞かなくなる」という悩みは、実はプロンプトの書き方が悪いのではありません。AIに「判断」と「実行の管理」の両方をさせている設計に問題があるのです。現在のトレンドは、AIの周囲をガチガチに固める「ハーネス（Harness）」という概念です。これは、AIという不安定な「脳」に対して、信頼できる堅牢な「身体」を装着させるという考え方です。

ここが面白い

多くのプロジェクトが失敗するのは、AIにリトライロジックやエラーハンドリングを任せてしまうからです。「うまくいかなかったらもう一度考えて」という指示をプロンプトに書くのは、もうやめましょう。それは、プログラム側で制御すべき古典的なアーキテクチャの役割です。AIには「判断」という高コストな作業だけをさせ、それ以外はコードで制御する。この切り分けができるかどうかが、プロのエンジニアと「ごっこ遊び」の違いです。

落とし穴は、AIを信頼しすぎてしまうことです。AIが生成したコードが完璧に動くのは「今」だけかもしれません。データが変わったり、周辺環境が変わったりした瞬間に崩壊するようなシステムは、運用に耐えられません。だからこそ、AIの出力結果を検証する仕組み（バリデーション）を、AIの外側に配置する必要があります。

日本の読者ならどう見るか

日本の開発現場では、往々にして「AI導入＝コスト削減」という短絡的な目標が設定されます。しかし、この「ハーネス」を構築するコストを無視してAIを導入すると、後からメンテナンスコストが爆発し、結果として高くつきます。「AIを入れれば楽になる」という幻想を捨て、システム工学の基本に立ち返る勇気が必要です。

試す前の実用メモ

• 「AIが全部やってくれる」という前提を捨てる。
• AIの出力が正しいかを確認する「テストコード」をAIに書かせる。
• リトライ処理やエラー処理は、AIのプロンプトではなく、プログラム（Pythonなど）側で実装する。

まとめ

今回紹介した3つのトピックに共通しているのは、「AIを魔法の杖にするな」という冷徹な視点です。プロンプトの書き方を工夫する（Topic 1）、非エンジニアがツールを作る（Topic 2）、AIの外側に堅牢な仕組みを作る（Topic 3）。これらはすべて、AIという不確実な技術を、ビジネスという確実性が求められる場所にどう落とし込むかという共通の課題に対する答えです。結局のところ、AIがどれだけ賢くなっても、それを使いこなす側の人間が「これは何が得意で、何が不得意か」を論理的に判断できなければ、ただのおもちゃに過ぎません。皆さんも、まずは小さなタスクから、AIを「部下」としてではなく「精度の高い計算機」として扱う練習を始めてみてはいかがでしょうか。