はじめに
マークダウンのメモアプリ Sirusita を、Claude Code にほぼすべて書いてもらって作りました。最後は Microsoft Store で公開しています。
- 技術スタック: Wails v2(Go)+ Svelte 5 + Monaco Editor
- 配布: GitHub Releases / Microsoft Store / Web 版(GitHub Pages)
この記事では、コードの中身よりも「AI に開発を任せるための環境と進め方」で工夫した点をまとめます。どの話も深入りはせず、ほかの人が試せそうなところを広く拾いました。
全体の流れ
Docker Sandboxes の中の Claude Code
├─ コードを書く・テストする(Go / Node / Wails はすべて Docker の中)
├─ gh コマンドで GitHub を操作(push、Actions の結果確認)
└─ CLAUDE.md の更新(AI に任せる)
│ v* タグを push
▼
GitHub Actions
├─ release.yml … Windows の exe を作って Release に添付
├─ msix.yml … MSIX を作って Artifact に置く
└─ pages.yml … Web 版を GitHub Pages に公開(main への push で)
│ MSIX をダウンロード
▼
Partner Center(ここだけ手作業)… MSIX を登録して申請
1. Claude Code に入れたもの
superpowers(作業の手順を決めるスキル集)
superpowers は、Claude Code に「作業の進め方」を教えるスキル集です。ブレインストーミング、計画、TDD、デバッグ、「完了と言う前に検証する」といった手順が入っています。
特に効くのは「検証してから完了と言う」です。「直しました」と言う前にテストを実行し、その結果を見せるようになります。
Context7(ライブラリの最新ドキュメントを引く MCP)
Svelte 5(runes)や Vite 7、Tailwind CSS 4 は、AI が学習した時点から書き方が変わっていることがあります。Context7 を入れ、ライブラリの話になったら先に最新のドキュメントを引くように指示しました。
指示はグローバルの ~/.claude/rules/ に置いたので、どのプロジェクトでも効きます。
AWS MCP
Web 版の独自ドメインは Route 53 で管理しています。AWS の作業も Claude Code から頼めるように、AWS MCP も入れました。
2. Docker Sandboxes で --dangerously-skip-permissions を使う
Claude Code は、ファイルの編集やコマンドの実行のたびに許可を求めてきます。安全ですが、長い作業だと何度も止まります。
--dangerously-skip-permissions を付けると確認なしで進みますが、手元の PC でそのまま使うのは怖いです。そこで Docker Sandboxes(sbx コマンド)を使いました。エージェントを microVM の中で動かす仕組みで、サンドボックスごとに Docker デーモン・ファイルシステム・ネットワークが分かれています。
sbx run claude --branch my-feature
sbx run claude で起動すると、Claude Code は最初から --dangerously-skip-permissions 付きで立ち上がります。ただ、私は VS Code から作業したかったので、次の順で使っています。
- サンドボックスを bash(シェル)で起動し、SSH を有効にする
- VS Code の Remote - SSH で、サンドボックスに接続する
- VS Code のターミナルで、Claude Code を起動する
claude --dangerously-skip-permissions
こうすると、AI には確認なしで作業させつつ、変わったファイルは VS Code で開いて確かめられます。
Claude Code にも、組み込みのサンドボックス(/sandbox)があります。それでも Docker Sandboxes を選んだ理由は 2 つです。
- 組み込みのサンドボックスで隔離されるのは、Bash のコマンドだけ。ファイルの編集ツール、MCP サーバー、hooks は、ホストの上でそのまま動きます。Docker Sandboxes なら、Claude Code のプロセス全体が microVM の中に入ります
-
組み込みのサンドボックスは
dockerコマンドと相性が悪い。公式ドキュメントでもdockerは非対応とされていて、使うにはexcludedCommandsでサンドボックスの外に出す必要があります。このプロジェクトはビルドもテストもdocker runで行うので、それでは肝心のコマンドが隔離の外で動いてしまいます。Docker Sandboxes にはサンドボックスごとに専用の Docker デーモンがあるので、docker runも隔離の中で動きます
隔離された中だから、確認を省いて任せられる。Docker Sandboxes と --dangerously-skip-permissions の組み合わせで、「テストが通るまで直して」のような長い作業を放っておけるようになりました。
ただし、サンドボックスに GitHub の認証情報を渡していれば、push などの外部への操作はできてしまいます。何を任せるかは決めておく必要があります。
外部へのアクセスも絞っています。Docker Sandboxes は最初の設定で、ネットワークの方針を 3 つから選べます。
- Open: すべて許可
- Balanced: 基本は拒否し、開発でよく使うサイトだけ許可
- Locked Down: ほぼすべて拒否
私は真ん中の Balanced を選びました。足りないサイトが出てきたら、そのつど sbx policy で許可に足しています。最初から全部開けるよりも安全で、全部閉じるほど手間もかかりません。
あわせて、ビルドもすべて Docker の中で完結させています。ホストには Go も Node も入れていません。
docker run --rm -v "$PWD":/app -w /app wails-dev go test ./...
docker run --rm -v "$PWD":/app -w /app wails-dev wails build -platform windows/amd64
手元で確かめるときは、Windows の exe も mingw-w64 を使って Linux のコンテナの中でクロスビルドできます。AI に「ビルドして確かめて」と頼むとき、環境の違いで悩まずに済みます。
3. CLAUDE.md のメンテナンスも AI に任せた
CLAUDE.md は、プロジェクトの説明を Claude Code に毎回読ませるファイルです。この更新も AI に任せています。ファイルを増やしたら構成の一覧に足す、ハマったことは注意点として残す、という具合です。
実際に CLAUDE.md に残った注意点の例です。
-
svelte.config.jsのvitePreprocess({ script: true })は必須。flowbite-svelte が TypeScript 入りの.svelteを配布していて、これがないとビルドが壊れる - MSIX を作る PowerShell スクリプトは ASCII だけで書く。Windows PowerShell 5.1 は BOM なしのファイルを ANSI として読むため
- Web 版は外部の CDN を使わない(プライバシーの方針)。そのため Google Fonts もやめた
人間がこまめに書き足すのは続きません。AI に「同じ失敗を次の自分(AI)がしないように書いておいて」と頼むと、自然に育っていきます。ときどき読み返して、古くなった記述を消すように頼む程度で十分でした。
4. GitHub の操作は MCP ではなく gh コマンドで
GitHub には公式の MCP サーバーもありますが、このプロジェクトでは gh コマンドを AI に使わせることにしました。理由は 3 つです。
-
AI が
ghをよく知っている。学習データに使い方がたくさんあるので、説明しなくても使える -
できることが広い。
gh apiで REST API を直接呼べるので、MCP にない操作もできる(例: GitHub Pages の状態の確認や設定の変更) -
出力を絞れる。
--jsonと-q(jq の式)で必要な項目だけ取り出せるので、出力をそのまま読むより、コンテキストの消費を抑えられる
たとえば、push したあとの Actions を待って結果を見るのはこうです。
gh run list --limit 3
gh run watch <run-id> --exit-status
Web 版の HTTPS がうまく有効にならなかったときも、gh api repos/<owner>/<repo>/pages/health を見て、証明書がまだ発行されていないことを AI が自分で突き止めました。
5. MSIX のビルドは GitHub Actions で完結
Microsoft Store に出すには MSIX というパッケージが必要です。MSIX を作る MakeAppx は Windows SDK のツールで、Windows でしか動きません。Linux で作る方法もありますが、公式の手順どおりに確実に作れるよう、ここだけ GitHub Actions の windows-latest で作ることにしました。
-
v1.7.0のようなタグを push すると、exe の Release 用と MSIX 用のワークフローが同時に動く - タグの
X.Y.Zを、そのまま MSIX のバージョン(X.Y.Z.0)に使う - MSIX は未署名のまま Artifact に置く。Store が審査のあとで署名してくれるので、証明書を用意しなくてよい
ワークフローで気をつけたのは、タグ名や入力値を run: の中に ${{ }} で直接書かないことです。env: を経由して渡します。直接書くとスクリプトとして解釈されるおそれがあるためです。
- name: Decide version
shell: bash
env:
INPUT_VERSION: ${{ github.event.inputs.version }}
run: echo "version=${INPUT_VERSION}" >> "$GITHUB_OUTPUT"
6. Store への登録はあえて手動に
Partner Center への申請も API で自動化できますが、手動のままにしました。
- 申請の回数は多くないので、自動化の手間に見合わない
- Partner Center の認証情報を CI に置かなくてよい
- 説明文やスクリーンショットは、どうせ人間が見て決めたい
その代わり、Partner Center に入力する内容は docs/store-submission.md に控えとして全部書いてあります。AI に書かせたものです。説明文、キーワード、年齢区分の回答、runFullTrust が必要な理由(Wails のデスクトップアプリなので)、審査担当者への注意書きまで入っています。次の更新では、Artifact から MSIX をダウンロードし、控えをコピーして貼るだけで終わります。
Store に出してみて分かったことも少し書いておきます。
- 製品の種類は「MSIX または PWA アプリ」を選ぶ。あとから変えられない
- プライバシーポリシーの URL が必須。リポジトリの
PRIVACY.mdの URL を使った - スクリーンショットは 1366×768 以上が 1 枚以上必要
7. そのほか、やってよかったこと
-
Web 版も作った。Go の部分(D2 の図の描画やインポートの解析)を WebAssembly にして、同じ画面をブラウザで動かしています。「インストールせずに試せる」入口があると、紹介しやすくなります
-
サンプル集をアプリに同梱。言語の文法やコマンドのチートシートも AI に書かせました。そのうえで、「載っているコマンドの誤りを確かめて」「表が崩れていないか見て」と、AI に見直しもさせています
-
生成物はスクリプトから作り、CI で確かめる。A4 横の SVG チートシートは手で書かず、Node のスクリプトで生成しています。CI では、生成結果が最新か、詳しい版のメモと内容が合っているかを確かめます。AI が「直接 SVG を手直し」して、元のデータとずれるのを防ぐためです
-
コミットのプレフィックス(
feat:/fix:/chore:)を決めておく。これを CLAUDE.md に書いておけば、AI のコミットメッセージもそろいます
まとめ
- 隔離環境(Docker Sandboxes)を用意すると、AI に確認なしで長く任せられる。
dockerを使うプロジェクトでは、組み込みのサンドボックスより Docker Sandboxes が合う - superpowers で進め方を、Context7 で最新の知識を、CLAUDE.md でプロジェクトの記憶を補う。CLAUDE.md の更新も AI に任せる
- GitHub の操作は
ghで十分。むしろ扱いやすい - 自動化は「ビルドまで」にして、Store への申請は手動。その代わり手順と入力内容は文書に残す
Sirusita の紹介
最後に、できあがったアプリの紹介です。
Sirusita は、技術メモやコマンド集をマークダウンで書きためる、開発者向けのシンプルなメモアプリです。編集機能は Obsidian ほど多くありません。その代わり、マークダウンや図・数式の書き方をまとめたサンプル集を最初から同梱し、書き方に迷ったらすぐ引いて、そのままメモに追加できるようにしました。分割表示でプレビューを横に見ながら書けるので、マークダウンを覚えながら使えます。
ちなみに Sirusita という名前は、Markdown を mark + down に分けて和訳した「印+下=しるした」から付けました(メモを「記した」にも掛けています)。
もう 1 つ工夫したのが階層タグです。技術メモは数が増えるとタグも増えて探しにくくなるので、プログラミング/Go のように / で区切ったタグを、サイドバーでツリーとして表示するようにしました。
▾ プログラミング (5)
Go (1)
Rust (1)
▾ コマンド (6)
docker (2)
- 親のタグ(
プログラミング)を選ぶと、その下のタグが付いたメモもまとめて表示される -
a/b/cを付けるだけで、途中のaとa/bも自動でツリーに出る - タグ名を変えると、その下のタグもまとめて付け替わる。
PlantUMLを図表/PlantUMLに変えれば、あとから階層の下へ移せる。作成・更新日時は変わらない
主な機能は次のとおりです。
- マークダウンで書いて、横のプレビューで確認できる。数式(KaTeX)、図(Mermaid / D2)、コードのシンタックスハイライトに対応
- 階層タグでメモを整理(上で紹介した仕組み)
- チートシート集を同梱。Go・Rust・Python などの文法、Docker・Git・bash のコマンド、正規表現などを、選んでメモに追加できる。Git・Docker・bash・正規表現には、A4 横の 1 枚にまとめた「1画面版」もある
- マークダウンや ZIP のインポートと、マークダウンのエクスポートに対応(ドラッグ&ドロップも可)
- オフラインで動作。メモは PC の中(Web 版はブラウザの中)だけに保存され、どこにも送信しない
| 入手先 | URL |
|---|---|
| Web 版(インストール不要) | https://sirusita.e17.click/ |
| Windows(Microsoft Store) | https://apps.microsoft.com/detail/9PPT0S6GKBLW |
| GitHub(MIT ライセンス) | https://github.com/morststs/sirusita |
触ってみての感想や要望は、GitHub の Issue やこの記事のコメントでいただけるとうれしいです。



