GLM-5.3をOpenCode実装担当に据えて分かった、権限設計と利用制限の教訓
OpenCode Go経由のGLM-5.3を、低温度・allowlist・タスク委譲禁止という狭い権限で因果的特徴量実装に起用した実測。制約の強い小タスクでは有望だったが、利用制限で継続運用は止まった。
OpenCode Go経由でクラウドのコーディングモデルを実装担当に据えるとき、「強そうなモデルを選べば速い」とは限りません。ある個人開発の株価予測アプリで、GLM-5.3を最初の実装担当として起用した実測記録から、権限設計と利用制限という2つの論点を見ていきます。
なぜGLM-5.3を最初に選んだのか
選定理由は「強そうだから」ではなく、ローカルの35B級モデルを立ち上げる前に、クラウド経由で小さなTDDタスクを素早く回せるかを確かめるためでした。担当したのは、予測器の土台になる適格ユニバース判定・コスト控除ラベル・7つの因果特徴量の実装です。この段階は画面の見た目より「未来情報をリークさせないこと」が重要で、モデルに自由なリポジトリ探索や仕様変更をさせると危険度が高い領域でした。
与えた実行契約：権限を先に狭める
OpenCode側のエージェント設定では、モデルをopencode-go/glm-5.3、温度を0.1、最大ステップを10に固定しました。
| 項目 | 設定・制約 | 意図 |
|---|---|---|
| モデル | opencode-go/glm-5.3 | OpenCode Goのクラウド実装担当 |
| temperature | 0.1 | 時系列計算での余計な設計変更を抑える |
| 最大ステップ | 10 | 長い自己探索より、閉じた実装を優先 |
| 読取・編集 | 特徴量ディレクトリ、対応テスト、合成CSVのみ | 変更の影響範囲を固定 |
| 禁止 | shell・glob・grep・Web検索・外部ディレクトリ・タスク委譲 | 環境依存の探索、秘密情報接触、脱線を防ぐ |
| テスト実行 | モデルには任せない | 親側がpytest・Ruff・mypyを独立実行 |
エージェントへ渡した原則も短く固定しています。
Never use future rows to compute an earlier eligibility, factor, feature, or label input.
Do not inspect plans, documentation, Git history, or unrelated code.
Do not run commands; the parent runs every test and quality gate.これは安全設定というより、生成品質を上げるためのプロンプト設計でもあります。LLMに自由度を与えすぎると、もっと便利そうな特徴量や外部データ、広域リファクタリングを持ち込みやすくなります。金融時系列のタスクでは、指定どおりの因果性とテスト契約を守ることこそが価値になります。
実装として残った成果
この範囲は後続コミットとして統合され、適格ユニバースの判定・往復コストの一貫した扱い・翌営業日寄付→引けのネット収益ラベル・7つの因果特徴量、それぞれの境界条件テスト、外部通信を使わない合成テストデータまで含めて、約1,100行の追加になりました。重要なのは行数ではなく、特徴量の実装とテストが同じ限定スコープに収まったことです。後段の予測モデルやUIへ手を広げず、まず「未来行を使っていないこと」を検証可能な単位にしています。
このコミットはレビュー担当が最終統合した成果であり、「GLM-5.3が1回の呼び出しで全行を正しく書いた」ことの証明ではありません。LLMの下書き、独立レビュー、テスト、最小修正を含む工程の成果として扱われています。
実測評価：強みと、記録の限界
| 評価軸 | 評価 | 根拠と限界 |
|---|---|---|
| タスク分解との相性 | 高い | 1層・数ファイルに固定したタスクを実装対象にできた |
| 因果性が重要な実装 | 条件付きで高い | 低温度・allowlist・テスト先行が前提。自由な生成の評価ではない |
| 大規模な横断実装 | 未評価 | 探索・シェル・タスク委譲を意図的に禁止したため |
| 速度・応答の実測 | 記録不足 | 比較可能なwall-clock、出力token、初回テスト合格率を残していない |
| 継続利用の信頼性 | 低い | OpenCode Goの利用制限に到達し、復帰待ちが発生した |
| 最終成果への寄与 | あり | 実装範囲は後続コミットに統合された。ただし単独寄与は切り分けない |
まとめると、「制約の強い小タスクでは有望だったが、今回の利用枠では主担当として計画を固定できなかった」という評価になります。ここで注意したいのは、利用制限をモデル能力の低さと誤認しないことです。GLM-5.3は与えられたタスクに対して実装成果も統合されていますが、途中からOpenCode Goの利用制限に達し、復帰時刻を待つ運用になったため、代替としてローカルのQwen3-CoderとOrnithへ切り替えています。連続した実装ラインに必要なのは、品質だけでなく「必要なときに次のタスクを実行できること」でした。
GLM-5.3の運用から得られた工夫
- モデルの賢さを期待する前に、権限を狭める。仕様・対象ファイル・禁止範囲が曖昧なら、強いモデルでも不要な変更を作ります。
- 数値・時系列ロジックは低温度に寄せる。低温度は正しさの保証ではありませんが、設計の再発明や余計な分岐を減らします。
- モデルにテスト実行を任せない。実行権限を持たせると、テストが通らない原因を環境や依存関係へ広げやすくなります。親側が同一環境で検証します。
- 利用枠をリスクとして設計する。レート制限・週次制限・障害時に、作業全体が止まらないようローカルモデルへ切り替えられる構成を最初から持っておきます。
- 評価記録を残す。次回以降は初回テスト合格率、修正回数、壁時計時間、利用制限・無応答・タイムアウトの別を同じ表で記録することが課題として挙がっています。
クラウド経由の実装モデルは、「賢いかどうか」だけでなく「必要なときに使えるかどうか」まで含めて評価する必要がある、というのがこの実測から得られる実務的な結論です。