apic

アプリからAPIへのコンパイラ。 エージェント向けAPIを持たないWebアプリを対象にします。コンピュータ操作エージェントがUIを探索し、実行して見つけたものを検証し、そのアプリ用の型付きMCPサーバーを生成します。

Playwright MCPは呼び出しのたびにアプリを解釈します。apicはそれを一度だけコンパイルします。

ロンドンで開催された{Tech: Europe} × VEEDハッカソン（2026年8月22日）にて、1日でソロビルド。

→ apic-ui.vercel.app — デモ動画、各パートナーモデルが決定した内容、コンパイラが測定した内容はこちら。

パブリックな消費者向けサイト

apic --read https://example.com は、あらゆる消費者向けサイトの公開された読み取り専用サーフェスをMCPツールにコンパイルします。そのサイト（オプションで同一サイトのシードも）から始め、検索ボックス、フィルター、繰り返し表示される結果カードを発見し、コールドリプレイに耐えた行を持つツールのみを生成します。Deliverooのルート、レストラン用語、アカウント、カート、チェックアウトを想定していません。

既知のコレクション/アイテムページの場合は、同一サイトの直接シードとして明示的に渡します：APIC_READ_DIRECT_URL=https://example.com/catalog/item apic --read https://example.com。エージェントが指定したURLは、レシピにコンパイルされたオリジンに制限されます。

1つのプロンプト、ターゲットURLなし

APICがMCPサーバーとして接続されている場合、通常の消費者向けの質問には compile_app の代わりに fulfill_request を使用します：

{ "request": "Find me the cheapest pizza near 17 & 18 Clere Street" }

サーバーはTavilyを使用して公開されている候補サービスを検索し、OpenAIを使用してコンパイルされたフローを選択・操作し、hを使用してあいまいな読み取りコントロールを優先し、Pioneerを使用してプローブが意味のある結果を出したかどうかを分類し、その分類に視覚的な判断が必要な場合にのみfalを使用します。候補がチャレンジされた場合やリプレイ可能な公開フローがない場合は、オリジンが異なる小さなフォールバックセットを試します。ログイン、注文、チェックアウト、チャレンジの回避は一切行いません。生き残ったツールはコールド検証され、証拠として返され、後続の呼び出しに備えて同じMCPサーバーに登録されます。

Related MCP server: mcp-apps-demo-engine

デモ

サイトで見る: apic-ui.vercel.app — 2分、ノーカット：コンパイル、生成されたツールがライブセッションに表示される様子、ウォッチャーがUIの変更を独自に検出する様子。

同じサイトに、このREADMEが報告する数値、パートナー別の内訳、すべてのMCPクライアント向けのインストールスニペットが掲載されています。

問題

コンピュータ操作エージェントは経済的にスケールしません。実行のたびにピクセルから同じ知識を再導出します。ステップごとのモデルラウンドトリップ、コンテキストウィンドウを埋め尽くすステップごとのページスナップショット、そしてチェーン全体で悪化の一途をたどる信頼性。だからこそ、デモは頻繁に行われても、本番展開はほとんどされないのです。

エージェントに操作してほしいソフトウェアこそ、APIを提供する可能性が最も低いソフトウェア、つまり社内ツール、レガシーシステム、ベンダーが消えてしまったようなソフトウェアです。何も表示されないネットワークタブをのぞき込むことはできませんし、2011年製の基幹業務アプリに新しいプロトコルの採用を求めることもできません。

apicは高価なエージェントを一度だけ使ってインターフェースを書き出します。その後は関数呼び出しにすぎません。

仕組み

修復パスはビルドパスと同じです。 修復はセレクタにパッチを当てるのではなく、そもそもツールを見つけたディスカバリーを再実行し、名前合成が生成する名前で照合します。名前が変更されたボタンでも、createProject は生成されます。

アプリが書き込みを確認した場合にのみツールは存在する

DOMノードを数えるだけでは、ページ上のすべてのボタンに対してそれらしいツールができあがります。apicは、アプリ自体が状態の変化を表明した場合にのみツールを生成します。3つの異なるアプリの動作をカバーする3つのシグナルを使用します：

移動が重要なのは、ドラッグにはバナーがなく、何もエコーバックされないためです。カードはすでに存在していたからです。コンテナの変化こそが証拠であり、外観上の再レンダリングではそれを生み出すことはできません。

レシピは場所ではなくIDにバインドされる

Vikunjaはページを読み込むたびに要素IDを再生成するため、保存されたセレクタは即座に使えなくなります。レシピはフィールドが何であるか（ラベル、プレースホルダー、名前）を記録し、リプレイ時にライブで再解決し、安定優先のセレクタチェーン（name → 安定ID → プレースホルダー → 生成IDの順）にフォールバックします。

結果

UIからコンパイル。コンパイル中にターゲットのOpenAPI仕様が読み取られることはありません。 スコアリングのグランドトゥルースとしてのみ使用されるため、再現率の数値に意味があるのです。

数値の前に分母を明記します： 18は、Vikunja自身のOpenAPI仕様の /projects、/tasks、/labels に対するすべての書き込み操作（POST/PUT/DELETE）のうち、ボード操作ではないもの（チーム、プロジェクトレベルの権限、リンク共有、添付ファイル、タスク関連、複製、一括エンドポイント、既読通知）を除いた数です。Vikunjaは合計105の書き込み操作を公開しています。18は人がかんばんボードで実行できるサブセットであり、生成された各ツールは最大でそのうちの1つを主張できるため、いい加減なマッチングで再現率が水増しされることはありません。

RECALL     8/18    of the board write-ops in the target's own API
PRECISION  9/9     emitted tools that map to a real operation
VERIFIED   9/9     survived a cold replay with arguments never seen before

9つのツールが発見され、9つが提供されました。拒否されたツールは削除されず、verified: false のまま tools.json に残ります。拒否されたツールはコンパイラに関する証拠であり、ゴミではないからです。

markTask は不安定で、それには9/9以上の価値があります。 同じバンドルに対する連続した2回の検証実行（間に変更なし）で、8/9、次に9/9という結果になりました。「ミューテーションは観測されたが、書き込みを確認できなかった」 というエラーで失敗し、その後 「成功 — タスクは正常に保存されました。」 で合格しました。原因はおそらくシードされたタスクの状態です。すでに完了しているタスクに遭遇すると、コントロールは「未完了にする」と表示され、確認方法が異なります。パラメータを取らないため、引数で曖昧さを解消することもできません。

これは、未解決として下に挙げた**「フレークとドリフトの問題」の実例**です。watch はその失敗をドリフトとして数え、何もドリフトしていないのに heal を呼び出します。

実際の午後の継続的検証：

327 checks · 118 breaks · 3 automatic repairs · MTTR 20s

（out/watch-stats.json、BST 11:33から38サイクル、これを書いている時点でもまだ実行中 — カウンターは動いています。）

そのブレーク数は、そのままの意味で読んでください。stats.breaks++ はすべてのサイクルのすべての赤いリプレイで発生するため、38サイクルにわたって赤のままの3つのツールは約114ブレークとしてカウントされます。これは赤いツールのサイクル数であり、118の個別のドリフトイベントではありません。そして、このウォッチャーは11:33に開始されましたが、これは heal() の修正前で、replay() のオープナーが実際にクリックする新しい provenance なしで修復されたレシピを返していました。そのため、コントロールの名前が変更されたツールは、サイクルごとに修復され、緑になることはありませんでした。それが6/9のほとんどです。コードで修正済みであり、同等の期間にわたって再収集されたものではありません。

パートナーテクノロジー

それぞれにステージがあり、それぞれがブロックするのではなく劣化します。パイプライン全体がAPIキーを一切使わずに、忠実度を落として実行されます。この特性があるからこそ、コンパイラは認証情報が届く前にビルド可能だったのです。また、コンパイルに気づかれずに統合が貢献を停止できる理由でもあり、それがステータス列に記録されている内容です。

2層分割は、製品自身のテーゼをそれ自体に適用したものである: falは安価で高頻度の知覚層、OpenAIは高価で低頻度の推論層である。 失敗時にエスカレーションし、すべての呼び出しでエスカレーションするわけではない。

それぞれが実際に呼び出される方法

h — holo3-1-35b-a3b、api.hcompany.ai/v1（OpenAI互換）。 gesture() は、コントロールの表示テキストを正規表現で <verb, resource> ペアにマッピングし、それ以外は null を返す。その null は精度のゲートであり、再現率が失われる場所でもある: アイコンのみのボタン、動詞で始まらないコントロール、または語彙が予期していない表現のアプリは、どれだけ明確に書き込んでもドロップされる。h はまさにそのセットのためのエスカレーション層である — discover.js の classify() は、ページのJPEGと拒否されたコントロールをシードごとに1回送信し、そのうちどれが書き込みかを尋ねる。

精度を損なわないようにする3つの点がある。回答は plan.gestureFrom() によって閉じた語彙（6つの動詞、4つのリソース）に対して検証されるため、でっち上げの動詞がツールに名前を付けることはできない。スライス外のコントロールは提供されずに保留される。ADD TO FAVORITES を除外することはスコープの決定であり、モデルが埋めるべきギャップではないからだ。また、分類されたコントロールも、他のすべての候補と同様に、アプリに書き込みを確認させなければならない。

測定結果（このREADMEが報告するコンパイル時）: h は、Vikunjaのタスクページで語彙が未解決のまま残す3つのコントロールを読み取り、そのうち1つを命名する — 正規表現が完全にドロップするアイコンのみのコントロールである。

! h read 3 unresolved controls, named 1
! h: "Kanban bucket: To-Do" -> move task (Pencil icon allows changing task status)

それがエスカレーション層の存在理由である: 先頭の動詞も利用可能なテキストもないコントロールを、アイコンから復元し、閉じた語彙にマッピングする。

それはツールを追加しなかったし、追加したと主張しているわけでもない。 move task はその時点で既に2回見つかっていた — ボードのドラッグ（Move card between columns）と、タスクページのバケットドロップダウン（Kanban bucket: Doing）によって。したがって、hの回答はドラッグが生成した moveTask に重複排除された。このターゲットでは、hは再現率ではなく裏付けである: 他の2つのルートが既に到達したアクションへの3番目の独立したルート。このファイルの以前の改訂版では、hは到達されず、何も命名しなかったと述べていたが、両方とも間違いだった。

h が再現率を追加するかどうかはここでは未検証である。Vikunjaの書き込みは異常なほどよくラベル付けされているからだ。hが構築されたケース — ボタンがアイコンであるアプリ — は、このターゲットが提示しないケースそのものである。キーがなければ、コンパイルはその裏付けを失うだけで、他には何も失わない。

fal — fal-ai/any-llm/vision 経由の google/gemini-2.5-flash-lite。 DOM差分はページが変更されたかどうかを判定する。テキストが説明しない変更 — 列を移動したカード、単に点灯したコントロール — を解決することはできない。perceive.js の adjudicate() は、それらのステップを、そしてそれらのみをピクセルにエスカレーションする。

測定結果（最後のフルコンパイルから）: vision: 4/4 escalated steps judged by fal, 1 drag corroborated, 2 found cosmetic。2つの外観的判定が興味深い半分である — falが、そうでなければ書き込みとしてプローブされたであろう候補を除去する。これは cli.js から実行される。MCPサーバー上の compile_app を通じて駆動されるコンパイルはエスカレーションしない。

OpenAI — gpt-4.1-mini、構造化出力。 verify.js は、アプリが一度も見たことのない引数で、発行されたすべてのツールをコールドリプレイし、結果を2回判定する: 最初に決定的な差分フロア、次にモデル。モデルは拒否を支持することはできるが、覆すことは決してない — 差分が確認できなかったツールは、判定者がどれほど確信していても拒否されたままになる。

測定結果: markTask が失敗した実行では、その記録は openai/gpt-4.1-mini disagreed but cannot overturn a rejection と読める。その非対称性は意図的である: 自身の推測を昇格させることができる判定者は、精度の漏れである。

Pioneer — GLiNER2（fastino/gliner2-base-v1）、ステップごとに1回の POST /inference。 distill.js は、各ステップの差分テキストを独自のリクエストで送信し、0.6の信頼度しきい値を超える状態変更クラス、破壊的フラグ、ドメイン名詞を受け取る。以前は軌跡全体をバッチ処理していたが、バッチ処理が下記の3番目の苦労して得た教訓の主題である: 同じテキストが単独では creation 0.777、位置0では creation 1.000、逆順バッチの位置2では DELETION 0.600 とスコアリングされた — 誤ったラベルがしきい値を通過した。PIONEER_MODEL に完了したトレーニングジョブIDを設定すると、ベースエンコーダがapic自身のラベルでファインチューニングされたチェックポイントに置き換わる — システムが自身の知覚層をコンパイルする — そして他には何も変更されない。

Pioneer — ファインチューニングされたverify判定者。 これはPioneerサイドチャレンジのエントリーである: 汎用LLM API呼び出しを上回る、または置き換えるモデルをファインチューニングする。 置き換える呼び出しは verify.js の judgeModel() である — GPT-4.1-mini、200語のシステムプロンプト、構造化出力、リプレイされたツールごとに1つの質問: このDOM差分が与えられたとき、予測された書き込みは実際に発生したか？ それはチャット補完をまとった2ラベルのテキスト分類である。

pioneer-train.js は、製品自身の排気から置き換えを構築する。手動ラベリングなしで:

1. collect — コンパイルされたすべてのツールを、verifyAll() を通じて新しい引数で6回リプレイし、エビデンスと、出荷された判定者（差分フロア+GPT）が与えた判定を記録する。54の実データ行。

2. dataset — フロアがキーとするエビデンスを削除してネガティブを導出する（バナーが消えた、エコーがそれを入力した入力に移動した、引数が未入力、リプレイが例外を投げた、何も変更されなかった）。ラベルを保持するポジティブも導出する（ノード順序を逆転、無関係なノードを追加、引数を人が入力する値にリネーム）。導出された各行は同じ決定的フロアによって再ラベル付けされる。788行。ツールごとに保留されるため、ベンチはエンコーダが一度も見たことのないツールを測定する。

3. upload / train — POST /felix/datasets/upload/url → presigned PUT → POST /felix/training-jobs、fastino/gliner2-base-v1、LoRA、12エポック。約4分でトレーニングされる。

4. bench — 保留された行を両方の判定者で評価する。LLMは変更されていない judgeModel() を介して呼び出されるため、本番で見るものとまったく同じものを見る。

215の保留行、トレーニングに含まれない2つのツール（createTask、assignLabel）。エンコーダはゼロの偽陽性のためにいくらかの再現率を犠牲にする — この判定者にとって正しいトレードオフである。設計上、拒否を支持することはできるが、推測を昇格させることは決してない。PIONEER_JUDGE_MODEL をジョブIDに設定すると verify がそれを使用する。OpenAIはフォールバックとして待機し、キーがまったくない場合でもフロアは実行される。

苦労して学んだ3つのこと。すべてライブで検証され、コードに記録されている: 分類仕様内の multi_label/top_k は、統合された /inference パスがすべてのテキストに対して categories: [] を返すようにする（これが、distilステージが午前中ずっと沈黙していた理由であり、クレジットではない）。GLiNER2はLoRAとしてのみトレーニングされる — training_type: "full" は受け入れられるが、Modal内でログ行なしで失敗する。そして、ファインチューニングされたモデルでのバッチ推論（text: [...]）は、入力と一致しないラベルを返すため、判定者はリクエストごとに1つのテキストを送信する。

Tavily — api.tavily.com/search、5件の結果、回答を含む。 ground.js は最初のシードの前に実行される。plan.js はVikunjaの名詞（bucket、task、label、project）を同梱しており、それ以外を指す場合、gesture() はそれらを聞かれたことがないテーブルによって問題やリポジトリについて尋ねられ、null を返し、コントロールはドロップされる。Tavilyはターゲット自身のドキュメントを取得する。OpenAIはその散文を厳格なスキーマの下で閉じた名詞セットに構造化する。すべての用語は /^[a-z][a-z-]{1,18}$/ に対して検証され、最大12個に制限され、組み込みテーブルを置き換えるのではなくマージされる。したがって、グラウンディングは語彙を追加でき、Vikunjaの語彙を奪うことは決してない。.apic/ の下にホストごとにキャッシュされるため、繰り返しのコンパイルはコストがかからず、デモは会場のWi-Fiに依存しない。

3段階で劣化する — Tavilyキーがないとエビデンスなし。OpenAIキーがないとエビデンスを構造化できない。検証を通過するものは何もない。それぞれがログを残し、組み込みテーブルをそのまま残す。falと同様に、cli.js から実行される。MCPサーバー上の compile_app は組み込み語彙を使用する。

したがって、上記の再現率の数値はキーレスで生成された、エスカレーションされた知覚ステップにはfal、verifyパスにはOpenAI判定者を使用した。これらは完全なパートナースタックのデモンストレーションではなく、このREADMEはそう見せかけようとはしない。

セットアップ

git clone https://github.com/brwbo/apic && cd apic
npm install && npx playwright install chromium
cp .env.example .env      # fill in keys; .env is gitignored
npm run setup             # starts the target app, checks every credential

ターゲットアプリ（セルフホスト、使い捨て — これを第三者の製品に向けてはならない）:

docker volume create vikunja-files
docker run --rm -v vikunja-files:/data alpine sh -c "chown -R 1000:0 /data"
docker run -d --name vikunja -p 3456:3456 -v vikunja-files:/app/vikunja/files \
  -e VIKUNJA_SERVICE_PUBLICURL=http://localhost:3456 \
  -e VIKUNJA_DATABASE_PATH=/app/vikunja/files/vikunja.db \
  -e VIKUNJA_RATELIMIT_ENABLED=false \
  vikunja/vikunja:latest

すべてのコマンドは同じ2つの変数を読み取るため、実行全体をライブのバンドルに触れることなく代替バンドルに向けることができます:

APIC_OUT_DIR=out/rescue APIC_APP=vikunja npm run verify

シードとターゲットは環境駆動です — コンパイラ内の何もVikunjaのルートを知りません:

APIC_APP=gitea TARGET_URL=http://localhost:3001 APIC_SEEDS=/repo/create,/issues npm run compile

生成された出力

generated/vikunja/ — サーバー、スキーマ、各ツールの証拠。そのディレクトリ内のものは人間によって書かれたものはありません。

MCPサーバーとして使用する

claude mcp add apic -- node /path/to/apic/src/server.js

src/server.js は 1つのツール compile_app から始まります。それをURLに向けると、パイプラインをインプロセスで実行し、generated/<app>/ を出力し、コンパイルされたツールをそれ自体に登録し、notifications/tools/list_changed を送信します — そのため、再起動なしで同じ接続上で呼び出し可能です。コールドスタートから:

[apic] ready - 0 compiled tools + compile_app
BEFORE compile, tools/list = [ 'compile_app' ]
compile_app returned in 22.1s
list_changed notification: YES
AFTER compile = [compile_app, createProject, createLabel, updateLabel, createTask]
createLabel -> {"ok":true,"effect":"creation","expected":"creation"}

拡張したばかりのものを再起動する必要があるコンパイラはビルドステップです。そうでないものはライブコンパイラです。クライアント互換性のメモと完全なトランスクリプト: docs/mcp-client.md。

両方の行き止まりは報告されるのではなく、回答されます

クライアントがapicに遭遇するのは何かが欠けている瞬間だけであり、その両方の瞬間が会話を終わらせていました。

存在しないツールは、それを作成するコンパイルを返します:

unknown tool: createIssue

No compiled tool exposes that action (compiled so far: vikunja). If the app has no API for it, make one:

    compile_app { "url": "http://localhost:3456", "goal": "createIssue" }

アプリが下から移動させたツールは呼び出しパス上で修復されます — watch はタイマーで修復し、サーバーはオンデマンドで修復します。同じ heal() を通じて。ツールが赤くなり、コンパイラがその1つのアクションを再探索し、修復が tools.json に書き戻され、呼び出し元が失敗を見る前に呼び出しが再試行されます:

[apic] createLabel is red (no control matched "ADD LABEL (RENAMED)") - re-exploring to heal it
[apic] createLabel healed in 13.6s (click "…" -> "create label"; selectors re-resolved); retry passed
{ "ok": true, "effect": "creation", "healed": { "ms": 13589, "persisted": true } }

健全なツールはこれらすべてに影響されません: 同じ呼び出し、4.4秒、再探索なし。

関連研究、およびこれとの違い

ループは新しいものではありません — 能力がどこから来るかが新しいのです。 Alitaはインターネットを読んでツールを作ります; cli-printing-pressはネットワークを読みます; Easy MCPは仕様を読みます。apicはアプリを読みます。

まだ機能しないもの

• hはパスにあり、このターゲットには何も貢献しません。 語彙が拒否したコントロールを読み取り、それらのどれも正しく名前を付けません。なぜならVikunjaのボードスライスはすでに正規表現でカバーされているからです。エスカレーションは実際にあり、測定されています; ここでの利得はゼロであり、コントロールが動詞句ではなくアイコンであるターゲットがそれを示すケースです。

• compile_app は縮小されたパイプラインを実行します。 compile.js はMCPサーバーが呼び出すインプロセスコンパイルであり、cli.js から5つのものを除いたものです: グラウンディング（Tavily/OpenAI）、シード発見、専用フォームページプローブ、タスク詳細シード、かんばんドラッグ、さらにfalのビジョンティア — adjudicate() は cli.js からのみ実行されます。発見、永続化、Pioneer蒸留、合成、出力は保持します。そのため、上記のトランスクリプトでは npm run compile が9つのツールを生成するのに対し、4つのツールが表示されています: ライブコンパイラデモと9ツールバンドルは2つの異なるパスであり、再現率の数値が説明するのはCLIのものだけです。

• Pioneerは午前中ずっと利用できないように見えました — 最初は 403 payment_method_required、新しいキーの後は毎回の呼び出しで categories: [] となり、コードはそれを「意見なし」と読み取り、ヒューリスティックにフォールスルーしました。2つ目はリクエスト形状のバグ（multi_label/top_k）であり、APIではありませんでした。各統合は静かに劣化するように書かれており、それぞれがそうしました — 劣化は意図された動作です; 午前中ずっと気づかなかったことはそうではありません。

• ファインチューニングされた判定者は1つのアプリしか見ていません。 その788のトレーニング行はすべてVikunjaです。保留された分割はツールごとであり、アプリごとではありません; GiteaまたはParaBankのベンチが次の正直なテストであり、2番目のターゲットに対する collect がそれを得る方法です。

• 2番目のターゲットは薄くコンパイルされます。 Giteaは現在エンドツーエンドでコンパイルされます — createRepository と createIssue、両方とも検証済み、swagger.v1.json に対してそのイシュースライスで2/13。発見には変更は必要ありませんでした: 2つの修正は確認クラス（Giteaは提出された値を運ぶ新しいURLで結果を提供することで書き込みを確認し、ゲートはバナーとボディエコーのみを探していました）と、コンテナ/アイテムURLパターンを cli.js から設定に移動することでした。そこには APIC_SEEDS がすでにありました。ラベルとコメントのアクションはまだ見逃されています: それらは語彙が名前を付けないコントロールの背後にあり、h は渡された14のうちどれも名前を付けませんでした。

• Vikunjaでの再現率8/18。 欠落: バケット作成、コメント、リレーション、添付ファイル。

• markTask はおよそ2回に1回失敗します（Results参照）。効果は実際にあり観察されています; 何かが確認するかどうかはタスクの既存状態に依存します。ライブの npm run verify は8/9または9/9を出力することが期待されるべきです。

• 同時実行は衝突します。 すべてのコマンドは .apic/session.json の1つの保存されたセッションを共有するため、一緒に開始されたコンパイルと検証は実行中に互いのブラウザコンテキストを破壊する可能性があります（Error setting storage state: Execution context was destroyed）。回避策として実行ごとに異なる APIC_SESSION を渡してください; 本当の修正はデフォルトで実行ごとのセッションファイルです。

• Watchはすべての失敗をドリフトとして扱います。 実際のフレーク対ドリフトの分類は存在しません。3つの偽陽性クラスが手動で修正されました — レート制限、トークン期限切れ、クラッシュしたページ — しかし一般的な問題は残っています。

• 意味的変更は検出されず危険です。 deleteProject が削除ではなくアーカイブを開始した場合、セレクタを修復するのは間違った答えです。検証は効果が発生したことをチェックしますが、それが同じ効果であることはチェックしません。

• 逆アクションがないため、スイートは自身のフィクスチャを汚染します。繰り返し実行すると、リセットされるまでターゲットが劣化します。

• 認証は回避されています。 1つのログイン、1人のユーザー、権限スコープなし — これは実際のエンタープライズソフトウェアにおける問題の難しい部分です。

先行研究の宣言

ハッカソンでゼロから書かれました。ボイラープレートは持ち込まれていません; リポジトリはイベントの朝に空で作成されました。Playwright、MCP SDK、OpenAIおよびfalクライアントが唯一の依存関係です。

ライセンス

MIT