現在は2026年1月11日、日曜日、未明です。
昨日、Hoboと一緒に昼食をとりました。久しぶりの再会で、食卓では多くのことを話し合い、彼は私たちの近況や仕事について非常に気にかけてくれました。たくさんの意見交換ができました。
外資系企業で働く彼が、GPTやClaude OpusなどのLLMを無制限に仕事の補助や効率化に使えるのがとても羨ましく思いました。それに比べて、私たちの国内の仕事環境では、これらのツールの使用にはまだ多くの制限や不便があります。
私たちの共通認識は、現在のコーディング作業において、LLMが書いたコードはそのまま本番環境に投入することはできない、非常に非常に信頼性に欠けるということです。
可観測性
私は彼に尋ねました。もし一つのモジュール内に限定し、厳格な単体テストとベンチマークテストを通過した場合、使用できるでしょうか？彼は補足して、さらに優れた可観測性も必要だと述べました。結局のところ、長期間にわたるサービスの安定性を考慮しなければならないからです。 さらに、巨大なシステムを、そのように明確に定義された小さなモジュールに分割すること自体、非常にコストがかかるものです。
これは確かに私が以前見落としていた問題です。この記事で触れたように、インターフェーススタイルテスト、単体テスト、ベンチマークテストを通過して初めて、人はLLMが生成したコードを信頼できるようになります。 かつて私がベンチマークテストを構築した際、CPUとメモリ使用量を考慮すると、通常のベンチマークテストだけでは、LLM生成コード内のパフォーマンス問題を発見できませんでした。問題を見つけるには、事前に負荷テストを行う必要があります。 負荷テストもまた、本番環境における様々な複雑なシナリオを真にシミュレートすることはできません。ですから、最終的には非常に優れた可観測性がなければ、本番環境でLLM生成コードを使用することはできません。
しかし、可観測性はどのように設計し、テストすべきでしょうか？
可観測性自体も、実際の状況が期待通りであるかをテストするためのツールです。ただ、その実行環境がテスト環境ではなく、本番環境にあるという点が異なります。
さらに、十分な情報を収集するためには、実装コードに侵入する必要があるかもしれません。（侵入型の計装は通常、より高い保守コストを意味します）
インターフェースの外部や環境情報から単純にいくつかのメトリクスデータを収集するだけでは、問題の一部しか発見できないことがよくあります。 例えば、モジュール内部の状態が正しいか、過剰なリソースを占有していないか、メモリリークがないか、デッドロックがないかなどを観測することはできません。
また、可観測性のメトリクスは、多くの場合、CPU、メモリ、I/Oなど、リソースの分離に関連しています。もし非常に優れたリソース分離がなければ、問題を発見することは難しいでしょう。
そして、可観測性の鍵はアラートシステムにあります。Hoboはかつて、「すべての計装メトリクスは、それに対応するアラートルールが存在することを暗示している。そうでなければ、その計装は意味がない」と述べていました。
通常の実践では、アラートルールは運用作業ですが、計装は開発作業です。おそらく、この実践自体に問題があるのかもしれません。なぜ、コード内に直接アラートルールを組み込むことを考えないのでしょうか？
例えば、各計装ポイントはアラートルールの定義を保持することができ、メトリクスが特定の閾値を超えたときに自動的にアラートをトリガーするようにできます。このようにすれば、開発者はコードを書く際に、直接可観測性とアラートルールを考慮に入れることができ、コードの品質と信頼性を向上させることができます。
例えば、計装と同時に、アサーション機構を設計することもできます。もしアサーションが通らなければ、アラートをトリガーします。これはエラー/警告機構によく似ていますね。エラー/警告ログを記録することは、それが注目される必要があることを意味するのでしょうか？
まずはログから始めることができます。エラー/警告ログを重点的に記録し、これらのログを可観測性の一部として、アラートシステムと組み合わせて、システムの信頼性を向上させることができます。
私はHoboの見解に非常に同意します：本番環境に投入するコードは、非常に優れた可観測性を持っていなければなりません。そうでなければ、長期間の安定性を保証することはできません。
LLMの知能レベル vs エンジニアリング手法
また、HoboはLLM自身の知能レベルがコード品質に与える影響についても言及しました。ここで私たちにはいくつかの意見の相違があります。
彼は、LLMの知能レベルがコード品質を決定する重要な要素であり、知能レベルが不十分であればタスクを完了できないと考えています。 一方、私は、LLMの知能レベルは確かに重要ですが、より重要なのは、タスクとテストプロセスをいかにうまく設計し、生成されるコードが期待通りであることを保証する方法だと考えています。
Hoboはエリートの能力、つまり天賦主義的な見方を好みます。一方、私はシステムの最適化、つまり構築主義的な見方を好みます。
どちらも正しいですが、段階が異なります。
モデルの能力の臨界点以下の場合、私は絶対に正しいです。現在の大多数の商業アプリケーションにとって、エンジニアリング手法の価値は、次の「より賢い」モデルを待つことよりもはるかに大きいです。注意深く設計されたプロンプトチェーン、完全なテストスイート、反復プロセスによって、能力が中程度のモデルでも、安定した使用可能なコードを生成することが完全に可能です。これは現在、AIアプリケーションを実用化する主流であり、成功への道です。
真の認知的限界に直面した場合、Hoboの見解が現れます。タスクの複雑さが、真の理解、抽象化、革新を必要とするレベルに達したとき（例えば、全く新しいアルゴリズムを設計する、あるいは極めて曖昧で矛盾した要求を理解する）、モデルの「知能の天井」は乗り越えられない障害となります。この時、どんなに優れたプロセスでも、モデルに「認知的に不可能なこと」を達成させることはできません。
私が代表するのは「エンジニアの現実主義」であり、現在AIに価値を創造させるための核心的な推進力です。 Hoboが代表するのは「研究者の先見性」であり、将来の能力の突破口に注目しています。
最も理想的な状態は、「エリートレベルの知能」に「エリートレベルのエンジニアリング手法」を組み合わせることです。
最高のプロセスを用いて、最も強力な知能を引き出し、制御することです。私たちの意見の相違は、正誤の違いではなく、焦点（現在の最適化 vs 根本的な突破）と時間スケール（短期間での実用化 vs 長期的な進化）の違いです。
チームにおいて、このような補完的な視点は非常に貴重です。
