Compactで「契約を書く言葉」を学びました。 このページは、開発者がじっさいに DApp（チェーンの上のアプリ）を作るときの流れと、役わりの分け方です。
なんのためにあるの？
Midnight のアプリは、契約を書いて終わりではありません。
「どの仕事を、どこで持つか」を分けて考えることが、いちばん大事。
契約（Compact）の仕事と、ふつうのアプリ（TypeScript）の仕事は、べつものです。
2つの「コンパクト」を混同しない
名前がにていて混乱しやすいので、最初に分けておきます。
⚠️ この2つは別々にバージョン管理されています。「CLI（取っ手）」と「コンパイラ（中身）」のバージョンを、ごちゃまぜにしないようにします。
契約・回路・アプリの関係
公式はこう説明しています。
「Compact のコンパイラは、台帳とのやり取りが正しいことを証明するゼロ知識回路を出力する」
つまり——
- 開発者：Compact で 契約 を書く
- コンパイラ：そこから ゼロ知識回路 を作る
- アプリ側（ふつうの TypeScript）：画面・入力・送信・結果の表示をたんとうする
「契約を書く層」と「Web アプリとして組み立てる層」を、分けて理解します。
だいたいの流れ
- 決める：何を公開し、何を秘密にし、何を「証明」だけで済ませるか
- 書く：その境目を前提に、Compact で契約を書く
- ビルドする：
compactコマンドのサブコマンドで契約をビルドする
- つなぐ：アプリ側が、入力・署名・送信・結果表示をつないで、ユーザー体験にする
compactコマンドには他にupdate/check/list/self updateなどのサブコマンドもあります（formatも追加予定）。
⚠️ 古い compactc は今は使わない
- 古いドキュメントに出てくる
compactcというコマンドは、いまは deprecated（非推奨） です。 - 公式は
compact compileに置きかえるよう案内しています。 - これから学ぶときは、
compactコマンド経由であつかうのが前提です。
Web アプリ開発者へのヒント
- Compact は「TypeScript ベース」と言われますが、ふつうの Web アプリの TypeScript と同じ気持ちでは書けません。
- 「文法が近い」と「考えかたが同じ」は別もの。証明が前提という制約をいつも意識します。
- 「バックエンドの API を増やす」感覚だけでなく、「契約・証明・公開状態の役わり分担」として考えると、すっきりします。
今日のまとめ
- アプリ＝契約（Compact）＋ ふつうのアプリ（TypeScript）の役わり分担
compact（CLI）と コンパイラ（ツールチェーン）は別バージョン- ビルドは
compact compile。古いcompactcはもう使わない
今はここだけでOK
「契約を書く仕事と、画面を作る仕事は別。まず『何を公開・秘密・証明にするか』を決めてから書く」——これでOK。
📘 もっと正確に（原文準拠コース）
Academy 原文に忠実な詳しい版はこちら：
つぎに読むページ
➡️ いよいよ手を動かす準備。開発環境の作りかた
📚 もっとくわしく（公式・むずかしめ）： Compact language（外部リンク・別タブで開きます） ／ Compact developer tools（外部リンク・別タブで開きます）