人工知能の活用が進む中、エンジニアリング分野における大規模言語モデル（LLM）アプリケーションの開発において、技術的な成功だけでなく、実際の現場での採用と信頼を得ることが最大の課題である。過去2年間、プロセスエンジニア、信頼性エンジニア、サイバーセキュリティアナリストなど、実務に携わる専門家と協働してLLMツールを構築してきた経験から、10の教訓をまとめた。これらは、単なる技術的アドバイスではなく、現場の実情に即した開発のあり方を示している。 まず、「すべての問題にLLMが必要ではない」（Lesson 1）。ルールベースや古典的機械学習モデルで80％の問題が解決できるなら、それらを優先すべき。数値の正確性や再現性が求められるタスクにはLLMではなく、分析モデルを活用すべきだ。また、人間の確認が入らない場合や、大量の処理をリアルタイムで行う必要がある場合は、LLMのコストと遅延が問題になる。 次に、「AIは補助であり、代替ではない」（Lesson 2）。開発者と専門家の間で「補強（augmentation）」という共通認識を築くことが不可欠。これにより、エンジニアは「AIに置き換えられる」という不安から解放され、ツールを積極的に活用するようになる。 「何が『より良い』かを明確に定義する」（Lesson 3）ことも重要。専門家と早期に協働し、現状の課題や許容できる誤差、誤りの種類を共有することで、「時間短縮」「誤検出の削減」など、具体的な評価指標を設定できる。 開発フェーズでは、「コ・パイロット、オート・パイロットではない」（Lesson 4）が鍵。完全自動化ではなく、中間結果を提示し、専門家が判断を介入できる仕組みを設計する。これにより、信頼が生まれる。 「フレームワークより、ワークフローとデータフローを先に考える」（Lesson 5）。初期段階では、LangGraphやAutoGenといった複雑なフレームワークではなく、シンプルなAPI呼び出しと制御構造でプロトタイプを構築する。これにより、実際の価値を迅速に検証できる。 「ワークフローから始め、エージェントは後回し」（Lesson 6）。エンジニアの実務には既に明確な手順がある。それをAIが再発見するのではなく、その知識を明示的にワークフローとして設計する。これにより、予測可能性と説明可能性が高まる。 「入力・出力・知識を構造化する」（Lesson 7）。自由テキストをそのまま入力すると性能が低下する。事故報告やログをJSON形式に構造化し、LLMに明確な根拠を提示させる。出力も構造化された形式で返すことで、システムとの連携が容易になる。 「分析AIと組み合わせる」（Lesson 8）。LLMにすべてを任せず、異常検知やクラスタリングには古典的AIを活用し、LLMはその結果を解釈・提案する役割に回す。これにより、精度と速度の両立が可能になる。 導入後は、「エンジニアが実際に使っている環境に統合する」（Lesson 9）。別々のWebアプリではなく、ログビューアーや監視ツールに直接機能を埋め込む。ボタン形式のタスク操作（「要約」「推奨手順」など）を提供することで、使いやすさが向上する。 最後に、「評価は導入後から始まる」（Lesson 10）。システムが「どうやって結論に至ったか」を可視化し、根拠や信頼度を提示する。専門家と実際の事例で評価会議を行い、フィードバックをもとに継続的に改善する。 これらの教訓は、LLMを「魔法の道具」と見なすのではなく、現場の知見と協働しながら、信頼できるシステムとして設計・導入するという姿勢の重要性を示している。技術の進化に合わせて、人間とAIの関係性を再定義することが、真の価値創出につながる。