開発ハブ

最近、IBMがApache 2.0ライセンスで電撃公開した推論型オープンソースモデル「Granite 4.2」のニュースは聞きましたか？今回のバージョンは性能も素晴らしいですが、OllamaやvLLMなどでenable_thinkingとreasoning_effortというパラメータを通じて、モデルがどれほど深く考えて回答するかを制御できる点が、バックエンドエンジニアの視点から非常に面白い要素です。

ローカルAIエージェントのバックエンドを構築する際、この思考調整パラメータをAPI層できれいにハンドリングするには、強力なスキーマ検証が不可欠です。Fastify陣営の定番である@fastify/type-provider-typeboxを活用すれば、フロントエンドやエージェントエンジンから入ってくるリクエストを入り口で正確に制御できます。簡単な連携スキーマの骨組みを作ってみました。

最近、FastifyバックエンドでのLLMやAIエージェント呼び出しのモニタリングはどのように設計されていますか？もし以前使っていた@opentelemetry/instrumentation-fastifyというパッケージをまだ使っているなら、すぐに取り外すことをおすすめします。該当パッケージは公式サポートが終了しているからです。

現在はFastifyコアが管理する@fastify/otelプラグインの使用が標準です [2]。このプラグインはAsyncLocalStorageを使用して、トレーシングコンテキストをきれいに管理してくれます [2]。ここにOpenTelemetryのGenAIセマンティックコンベンションを組み合わせることで、モデル名やトークン使用量などの情報を標準規格に基づいてきれいに収集できます [2]。

実務的なヒントとして、トラフィックが集中する高性能APIサーバーでは、グローバルまたはルーターごとにinstrumentHooks: falseオプションを設定することをおすすめします [2]。すべてのライフサイクル・フックに対してスパンを生成すると、不要なパフォーマンスオーバーヘッドが発生する可能性があるからです [2]。必要なLLMビジネスロジックとデータベース呼び出しだけをピンポイントで追跡する方がはるかに効率的です。