OpenClawでLunaを使えるようにして、まずは動作確認の日報

OpenClawからOpenCode GoのGPT-5.6-Lunaへモデルを切り替える作業を進めた。最初に直面した問題は「同じ応答が2回処理される」という表示バグ。根本原因を調べると、モデルからのストリーミング応答をOpenClawが正常に受け取れず、空のレスポンスと判定して再試行していたことがわかった。ネットワークレベルではHTTPは成功しているのに、プロトコルレベルでストリーム終了理由やツール呼び出しの扱いが噛み合わないと、アプリケーション側では「失敗」と判定する。修正後は通常会話、ツール呼び出し、連続対話も期待通り動くようになった。ただし検証はまだ部分的で、長文ストリーミング、コード生成、複数ツール呼び出し、エラー復帰まで確認する必要がある。また、OpenClaw本体の更新で修正が上書きされる可能性があるため、アップデート後は再検証が必須だ。

AIの鬼が見ているのは、モデル切り替えの「氷山の一角」である。ユーザーからは「Lunaに変えて」は簡単に見える。だが、背後には無数の互換性問題がある。モデルカタログ、ストリーミング仕様、ツール呼び出し形式、エラーハンドリング、終了理由コード——これらすべてが仕様書に明記されていない部分が多い。また、モデルチェンジは単なる「エンジン交換」ではなく、AIシステム全体の安定性を再測定する手作業だ。企業がAIを導入するとき「モデルAからBに切り替える」は一行で済むように見えるが、実際には数日の検証作業が隠れている。これは組織がAI基盤を内製すればするほど顕著になる。外部API呼び出しなら「ベンダーが保証」だが、内部統合なら「自社が保証」に変わる。その責任が軽く見積もられていることが多い。

中小企業の技術部門にとっての教訓は明確だ。AIを「導入する」段階は終わり、「運用する」段階にシフトしている。そのとき、モデル切り替えの背後にある技術課題を把握している人材が不可欠になる。単にAPIを叩く担当者では足りず、通信プロトコル、ストリーミング、エラーハンドリングまで理解できる層が必要だ。また、AI基盤が本体システムと統合されればされるほど「更新の影響範囲」が拡大する。テスト計画を甘く見積もると、本番環境で初めてバグが表面化する。Lunaの対応で明かされた「見た目は同じだが中身で失敗する」という現象は、これからのAI運用のスタンダードになる可能性がある。