計算をコードに落とす（Computation as Code）

再現可能な計算は、モデルに推論でやらせず、コードを書かせて実行させる。消えるのは誤差であって消費ではない — 答えが決定的になり、手続きが残るので検算できる。安くなるとは主張しない。どちらの経路が安いかは、誰も測っていない。

問題

数値の集計や換算がときどき狂う。しかも狂い方が見えにくい — もっともらしい桁の、もっともらしい数字が返ってくる。モデルは計算を推論として行うため、答えは確率的であり、同じ入力に同じ答えが返る保証すらない。「検算せよ」と命じても、検算もまた推論である — 推論の誤りを推論で確かめる循環からは出られない。テストの無い集計、手で確かめない合計、目視で通した換算が、その狂いを下流の判断まで運ぶ。

コンテキスト

適用する条件:

• 手続きが決まっている計算 — 集計・換算・差分・比率。入力と手順が決まれば答えが一意に決まるもの
• 同じ計算を繰り返す — 手続きを一度コードにすれば、以後は実行するだけになる
• 結果が下流の判断に効く — 狂った数字の上に判断が積み上がる場所

適用しないケース:

• 一度きりの概算。 コードを書くこと自体に費用がかかり、使い捨ての見積もりでは割に合わないことがある
• 計算ではなく判断であるもの。 「この見積もりは妥当か」はコードに落ちない
• 入力が曖昧で、正規化そのものが判断を含むとき。 何をどう数えるかが決まっていないなら、それを決めるのはコードの仕事ではない

隣接パターンとの境界:

• 機械ゲートと意味ゲートの分離 — 同じ発想の別適用である。 同パターンは検証を決定的な手段に載せ、本パターンは計算を決定的な手段に載せる。どちらも「決定的に出せる答えを、非決定的な手段に出させない」
• 権限を構造で縛る — 本パターンは同パターンと衝突しうる。コードを実行させるには実行権限が要る。権限を絞ったまま両立させる運用は具体例節で扱う
• 思考深度をタスクに合わせる — 同パターンは推論にどれだけ払うかのつまみ、本パターンはそもそも推論に向かない仕事を推論の外へ出す判断である

解決

計算を書かせて、実行させる。モデルの仕事を「答えを出すこと」から「答えの出し方をコードに書くこと」に変え、答えを出す仕事は機械に渡す。なぜ効くのか。二段で説明する。

第一に、決定性。計算は本来、決定的な手続きである。入力と手順が決まれば、答えは一つに決まる。それをモデルにやらせるとは、決定的な手続きを確率的な手段で近似することである。

近似は当たることも多い。問題は、当たったかどうかを見る方法が無いことだ — 推論経路で残るのは数字だけであり、その数字がどう出てきたかは残らない。

コードに落とすと、答えが正しいかどうかは別として、同じ入力に同じ答えが返ることは保証される。そして手続きがコードとして残るので、間違っていたときに、間違いを直せる。

推論の誤りは直せない — 次も同じ誤り方をするとは限らないからである。

第二に、移譲できる責任の範囲。「検算せよ」と命じる手もあるが、検算もまた推論である。推論の誤りを推論で確かめている限り、循環は閉じない。

計算をコードに落とすことは、この循環を切って、合っているかどうかの判定を機械に移すことである。この分離を計算に限らず検証全般へ広げたものが機械ゲートと意味ゲートの分離である。

このページの主張はここまでである。 「コードのほうが安い」とは主張しない。コードを書いて実行する経路も、トークンを消費する — コードを書く出力、ツール呼び出し、結果の読み取り。推論でやる場合とどちらが安いかを測った資料を、本カタログは持っていない。測っていないことを、測ったかのように書かないのが本カタログの規約である。費用について 公式 が言っていること（と、言っていないこと）は具体例節で扱う。

トレードオフ

利点

• 決定的になる。 再実行で同じ答えが返る。推論にはこの保証が無く、当たったかどうかを見る方法も無い
• 手続きが残る。 検算できる。間違いを直せる。同じ計算を繰り返すとき、そのまま再利用できる。推論経路は数字しか残さない

代償

• 実行権限が要る。 コードを走らせるとは、そのプロセスに何かをさせることであり、権限を絞る作業（権限を構造で縛る）と正面から緊張する。権限パターンで実行範囲を絞る緩和策はある（具体例節）が、緊張がゼロになるわけではない
• コードを書く費用がかかる。 一度きりの概算では、コードのほうが高くつきうる。そして「繰り返すならコードのほうが安い」とも本カタログは書かない — どちらの経路の消費が大きいかを測った資料を持っていない

GitHub Copilot での具体例

このパターンに対応する専用の機能は無い。 道具非依存の実践であり、どの面（VS Code / github.com / Copilot CLI / cloud agent）にも「計算をコードでやれ」と指示する機構は無い。道具が与えるのは場所 — コードを書いて実行できる環境と、その実行を許すか否かの権限 — までであり、その場所を計算に使うかどうかは運用の側にある。以下、Copilot CLI の面でこの実践を権限を絞ったまま行う運用と、VS Code の面で公式が費用について言っていることを書く。

Copilot CLI — shell の権限を絞って、書かせて実行させる

計算をコードに落とすには、書いたコードを実行させる必要がある。Copilot CLI ではシェル実行が shell というツールとして権限管理の対象になっており、許可の範囲を権限パターンで絞れる（出典: CLI command reference、取得日: 2026-07-16）公式:

The --allow-tool and --deny-tool options accept permission patterns in the format Kind(argument). The argument is optional—omitting it matches all tools of that kind.

〔訳〕--allow-tool と --deny-tool オプションは Kind(argument) の形式の権限パターンを受け取る。引数は省略可能であり、省略するとその種類のすべてのツールに一致する。

| shell | Shell command execution | shell(git push), shell(git:*), shell |

〔訳〕shell はシェルコマンド実行を表すツール種別であり、例として shell(git push)、shell(git:*)、shell のような権限パターンを取る。

引数を省略した shell はシェル全体の許可である。計算スクリプトを走らせるためだけに、そこまで開く必要はない。:* サフィックスは前方一致の取り違えを防ぐ形で範囲を絞る 公式:

For shell rules, the :* suffix matches the command stem followed by a space, preventing partial matches. For example, shell(git:*) matches git push and git pull but does not match gitea.

〔訳〕shell ルールでは、:* サフィックスはコマンドの語幹の後にスペースが続く形に一致し、部分一致を防ぐ。例えば shell(git:*) は git push や git pull に一致するが、gitea には一致しない。

公式の実例は、許可と拒否を重ねる形を示している 公式:

# Allow all git commands except git push
copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

評価順序も原文にある 公式:

Deny rules always take precedence over allow rules, even when --allow-all is set.

〔訳〕deny ルールは、--allow-all が設定されている場合でも、常に allow ルールに優先する。

⚠ この「deny 優先」の原文はツール権限パターンの節の記述である。URL の許可設定にも同趣旨の記述が別にあるが、そちらは URL の話であり、両者を混ぜて「Copilot は一律 deny 優先」と一般化しない。

この運用が本パターンの実務的な接続である。「コンテキスト」で述べたとおり、本パターンは**権限を構造で縛る**と衝突しうる — しかし全開にするか諦めるかの二択ではない。集計スクリプトを書かせて実行させるために必要な範囲だけを allow し、締めたい操作を deny で重ねれば、計算のためにコードを走らせることと、権限を絞ることは両立できる。

ただし取り違えないこと。これは「権限の与え方」であって、「計算をコードに落とす」機能ではない。 実行の場所と権限を与えても、モデルが計算を推論でやることは止まらない。「この集計は暗算せず、スクリプトを書いて実行して出せ」は、プロンプトや命令ファイルの側で言う — 道具は場所を与えるだけで、そこで計算せよとは言わない。

VS Code — 費用について公式が言っていること（と、言っていないこと）

計算を推論でやらせることには費用の側面もあり、VS Code の面では公式が思考の量と費用を因果で結んでいる（出典: Language models（カスタマイズ）、取得日: 2026-07-16）公式:

Higher thinking effort produces more thinking tokens, which increases AI credit consumption. Only increase thinking effort for genuinely complex tasks.

〔訳〕思考深度を高めるほど thinking tokens が増え、AI クレジット消費が増加する。思考深度を上げるのは、本当に複雑なタスクに限るべきである。

費用の全体像も同じ面にある（出典: Language models（概念）、取得日: 2026-07-16）公式:

Different models consume AI credits at different rates, based on the model and the number of tokens processed. More capable models cost more per token, while lighter models extend your usage further.

〔訳〕モデルが異なれば、そのモデルと処理するトークン数に応じて AI クレジットの消費率も異なる。高性能なモデルほどトークン単価が高く、軽量なモデルは利用可能な範囲を広げる。

Other factors also affect credit consumption, such as thinking effort (higher effort produces more thinking tokens), context window size, and tool usage. Prompt caching lowers the effective cost of a request by reusing tokens from a previous one.

〔訳〕クレジット消費には他の要因も影響する — 思考深度（深度が高いほど thinking tokens が増える）、コンテキストウィンドウのサイズ、ツールの使用などである。プロンプトキャッシュは、以前のリクエストのトークンを再利用することでリクエストの実効コストを下げる。

ここから「計算をコードに落とせば、その分の消費が消える」と結論したくなる。その結論は原文から出ない。 原文が言うのは「思考深度を上げると thinking tokens が増え、AI クレジット消費が増える」（VS Code の面）までである。コード経路も無料ではない — コードを書く出力とツール呼び出しでトークンを消費し、上の原文自身が tool usage を消費要因の一つに挙げている。二つの経路のどちらが安いかを測った資料を、本カタログは持っていない。本パターンの根拠は費用ではなく、決定性と検算可能性に置く。 つまみとしての思考深度の選び方は**思考深度をタスクに合わせる**が扱う。

別名

呼称	出典
計算をコードに落とす / LLM に電卓をやらせない / Computation as Code	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

このパターンには、確認できた範囲で確立した呼称が無く、対応する機構の名前も無い。道具非依存の実践だからである。他のパターンでは公式の機構名（Subagent、Prompt caching など）が近縁の呼称として別名表に載るが、本パターンにはそれに当たるものが存在しない。具体例節で挙げた shell のツール権限は「コードを実行できる場所」の作り方の名であって、この実践の名ではない。場所の名前を実践の名前として使うと、「shell を許している＝計算はコードでやっている」という誤解になる。実際には、場所があってもモデルは計算を推論でやりうる。

なお本パターンは、本カタログの収録判断の過程で一度落選し、復活した経緯を持つ。落選理由は「道具に対応物が無い」だったが、その判定基準そのものが誤りだった — 道具に依存しないことは、落選理由ではなく収録理由である。 最も一般的な実践ほど、道具固有の機能に対応物を持たない。

関連

• 機械ゲートと意味ゲートの分離 — 同じ発想の別適用。 同パターンは検証を、本パターンは計算を、決定的な手段に載せる。「決定的に出せる答えを、非決定的な手段に出させない」という同じ原則の二つの適用である
• 権限を構造で縛る — 正面から緊張する。 コードを実行させるには実行権限が要る。権限パターンで実行範囲を絞れば両立できる（具体例節）が、緊張がゼロになるわけではない
• 思考深度をタスクに合わせる — 同パターンは推論にどれだけ払うかのつまみ、本パターンはそもそも推論に向かない仕事（決定的な計算）を推論の外へ出す判断。どちらの経路が安いかは、本カタログはどちらのページでも主張しない
• 検証対象の明示 — 何を計算させるのかが曖昧なら、コードに落としても答えは的を外す。計算に先立って、対象の明示が要る
• まず次に読むなら 検証対象の明示 — 検算可能にしたら、次は何を検証するかを契約にする番である