Blog スタッフブログ

こんにちは、株式会社MIXシステム開発担当のBloomです。

以前のVSCodeへCodexを導入する手順についての記事からおよそ半年、毎日Codexを利用して開発していく中で実際に起きたトラブル事例と対処の備忘録を共有させていただきたいと思います。

利用モデルは概ねGPT-5系のその時々の最新版のうちミドルクラスのものを選択しています。

ファイルが消された

Codexを利用していくといつか必ず遭遇すると言っても過言ではないトラブルかと思われます。権限を最小にしていようが起きると言ってもよく、SKILL.mdでの抑制も怪しい部分があります。

Git管理しているプロジェクト上でなら多少ファイルを消されても管理対象ファイルであれば差し戻せますが、コミット前の変更であったり管理対象外ファイルで起こると悲惨です。

対処は単純で消されるものとしてバックアップを取りましょう、では元も子もないのでいざ削除された後のバッドノウハウを残していきます。

まず慌てて「元に戻して」とCodexに頼むのは傷口を広げる結果になりがちです。ファイル削除は他のファイル編集とともに行われる場合が多く、それも差し戻すといった命令と解釈される可能性があります。

まずは削除してしまったファイルを確認する命令を送ったあとで、リストアップしたあとに復旧を命令してみましょう。VSCodeの拡張機能でCodexを利用している場合、diffなどがチャット欄に表示されていることもあります。このdiffをCodexはおそらく完全に参照しているわけではなさそうなので、もし表示されているならそこからの人力復旧がおすすめです。

同じ作業をさせているのに段々と挙動が不安定になる

日次のデータ処理などを同じチャット内で処理させているといずれ発生する問題です。LLMへ送信するテキスト量が一定を超えてしまい細かい部分やルールなどを忘れてしまっているからとなります。

チャット量が増えると自動でコンテキスト圧縮が発生しますが、この圧縮の過程でも取りこぼしが発生します。

日次で行う処理などはある程度こなしたらSKILL.mdへ作業手順や細かいルールの書き出しを行わせ、別のチャットに切り替えて作業をしていきましょう。特に「いつもの」「前回と同じで」と命令するようになってきたタイミングで一度書き出した方がよいでしょう。絶対に遵守して欲しいルールがある場合はなおさら一度SKILL.mdへ記載させておきましょう。

実装方針や不具合についての調査を命じたらそのまま実装や修正した

これも使っていくと必ず起きると言っても過言ではないトラブルだと思われます。「調査してください」と記載していても勝手に実装されることがあります。特に不具合などは尚更勝手に修正しようとする傾向があるようです。

編集操作に気づいたらすぐ停止させるのが良いですが、なんらかの理由で気づかないこともあると思います。これもはじめの事例と同じで編集はされるものと考え対処しましょう。

使用量が想定より多い

ここ半年間でリリースされていたミドルクラスのモデルでは1つのプロジェクトを丸ごと実装させようとしない限り5時間制限を使い切るのも難しい程度には使用量がありましたが、唐突に使用量が底を尽きることがあります。

まずはチャットの途中で利用モデルを変更すると使用量を浪費しやすくなります。

モデルを変更すると、それまでの会話内容を新しいモデル側でも参照する必要があるため、長くなったチャットほど使用量への影響が大きくなります。特に長期間利用しているチャット内でモデルを何度も切り替えるのは避けた方がよいでしょう。

モデルはコロコロ変えず、変更する場合は必要な内容をファイルなどへまとめたうえで新しいチャットへ切り替える方が無難です。前述したコンテキスト圧縮が何度も発生するほど長いチャットも使用量が増えやすくなります。

依頼の作業範囲にも注意しましょう。命令によって参照するファイル数が増えれば増えるほど使用量を浪費します。「このプロジェクトの問題を丸ごと全て確認して」といった命令は特に危険で、余裕がない限りは特定のモジュールや処理に絞って確認を行わせるなど作業範囲を絞る工夫をすると良いでしょう。事前に自分で見立てた対象ファイルを添えるのも良いと思われます。

ここまでがここ半年間の経験則となります。これからも上手く付き合っていきましょう。