Anthropic主催Built with Opus 4.7ハッカソン体験記
AnthropicとCerebral Valleyが主催した1週間ハッカソンBuilt with Opus 4.7に参加し、僕はMoraというiPadアプリを作りました。世界中から20,000チーム以上が応募し、選出されたのは500チーム。その500チームの中に、僕も入れていただきました。6日間、有給休暇も使って参加し、寝食忘れて100+ PRのソロ開発を行いました。
先日、結果が発表されました。
上位3チームと特別賞3チームの計6チーム。残念ながら僕は入選なりませんでした。正直に書くと、めちゃくちゃ悔しいです。ただ、優勝のMedKitも2位のWrenchも、本当に素晴らしいクオリティでした。1週間足らずでこんなものが作れてしまう時代に、もう僕たちは生きているのだということを、改めて痛感する良い機会になりました。
そしてそれ以上に大きな収穫だったのは、この6日間でClaude Codeの使い方が何段階もアップグレードできたことです。後半でその話も書きますが、まずは何を作ったかから。
なぜMoraを作ったのか
僕の身近にいる子どもには、ディスレクシア（読字障害）があります。さらに英語を第二言語として学んでいる最中でもあります。 学校はとても親身で先生方も優秀です。彼のような子のためのIEP（個別教育計画）という、ディスレクシアに対する構造化された支援の仕組みも整っています。専門家、個別指導の時間、デコーダブルテキスト。文字の処理が普通とは違う子にとって、追いつけるか落ちこぼれるかを分ける、本当に大きな支えです。
ただし、ひとつ条件があります。 彼らの学区では、ディスレクシア向けの構造化された読み書き支援のIEPに到達するには、まずESL（第二言語としての英語）を卒業する必要があるようなのです。学校の言い分も理解できます。ディスレクシアと第二言語習得の困難を見分けるのは難しく、誤診を急ぐより慎重に観察する方が正しい。でも実際には、本当に必要なディスレクシア支援を受けられるまで1年近く待つことになります。アドボカシー次第でこれを短くできるかもしれないし、できないかもしれない。どちらにせよ、僕はその1年を、彼が立ち止まったまま過ごさせるのは嫌でした。
代替案も調べました。 Barton Reading & Spelling Systemは、Orton-Gillingham法に基づくディスレクシア向けの構造化リテラシープログラムとしてゴールドスタンダードと呼ばれるものです。地域にトレーニングを受けたチューターはいますが、1セッション$80〜$200。週2回、プログラム全体を通すと$15,000〜$30,000です。シングルインカムの家庭には、現実的な選択肢ではありません。
市販のフォニックスアプリも、良いものはたくさんあります。ただしどれも、学習者がネイティブの英語話者であることを前提にしています。L1（第一言語）が日本語の子に特有の置き換え、たとえば v を b、l を r、sh を s と発音してしまうケースは想定していません。子どもの発音を「間違い」として赤いバツを返す。すると子どもは「自分はこれが下手だ」と内面化してしまう。「b と v の違いをまだ習っていないだけ」という事実ではなく。
そんな経緯で、Moraを作りました。
Moraがやること
Moraは、Orton-Gillinghamフォニックス（Bartonの基盤と同じ多感覚構造化リテラシー）と、妖怪のメンターが登場するRPG的なシェルを組み合わせた、完全オンデバイスのiPadアプリです。
毎週、イラストの妖怪が、自分の声で吹き込まれた音声でその週の練習内容を紹介してくれます。妖怪のシェルが、毎日のフォニックスの練習をクエストに変える。ワークシートではなく、物語に。
その中身は、おおむね3つのことが起きています。
タイルボードによるデコーディング。タイルボードは、すべての単語を、学習者がすでに「明示的にマスターしたグラフィム」に分解します。sh のダイグラフを習うまでは ship は出てこない。画面に出てくるのは、常にデコード可能な単語であり、文脈から推測する必要はありません。
オンデバイスでの発音フィードバック。学習者がiPadのマイクに向かって単語を発音すると、INT8量子化された wav2vec2 の音素事後確率モデルが、CoreMLのオンデバイスで動きます。L1日本語の置換をエンジンが捕捉し、的を絞ったコーチングに変える。「/bɛɾi/ と聞こえました。/vɛri/ と言ってみましょう。前歯の上を下唇に軽く当ててみて」。赤いバツではなく、コーチング。
デコーダブル文の書き取り。妖怪が先に文を読み上げ、子どもが発音するとタイルが埋まっていきます。各文は学習者がマスターしたグラフィムの集合に対して生成されているので、常に解ける。設計上、フラストレーションが起きないようになっています。
譲れない一線：オンデバイス
子どもがユーザーである場合、オンデバイスのプライバシーは「機能」ではありません。「守るべき最低限の約束」です。
生の音声はiPadから外に出ません。テキスト化されたトランスクリプトも出ません。試行ごとの細かいログも出ません。 僕のサーバーにも、Anthropicのサーバーにも、Appleのサーバーにも。CoreMLモデルはローカルで動きます。セッションデータは端末上のSwiftDataの中に閉じています。今後計画している唯一のクラウド連携（親モード用のCloudKitプライベートデータベース同期）もオプトインで、家族単位のスコープに閉じます。
日本語ファースト、国際展開対応
MVPには JapaneseL1Profile だけを同梱しています。ただし、L1依存の判断（どの置換を聴くか、どの子音が一番難しいか、ヒントの足場としてどの仮名を使うか、など）は、すべて L1Profile というSwiftプロトコルを経由します。韓国語、中国語、スペイン語、ベトナム語の学習者を追加するのは、ロケールごとのデータ追加であってエンジンの書き直しではない。国際展開はロードマップに乗っています。
Built with Opus 4.7 —6日間で気づいた4つのこと
僕はもともとSwiftエンジニアではありません。それでも5日間で100以上の構造化されたPRを出しました。SPMパッケージ5本、ファイル数456。すべてのPRに仕様書（spec）と実装計画（plan）が紐づいていて、両方ともリポジトリにコミットされ、docs/superpowers/specs/ と docs/superpowers/plans/ に並んでいます。
このスプリントで気づいたことを、おおむね効いた順に4つ書きます。
1. superpowersスキルチェーンで、ワークフローはほぼドリフトしない
落ち着いたループはこれです。
superpowers:brainstorming → writing-plans → subagent-driven-development
ブレインストーミングで1ページの仕様に収束させ、計画作成でその仕様をチェックボックス駆動の実装計画に落とし、サブエージェント駆動開発で、フルコンテキストと2段階レビュー（仕様適合性、次にコード品質）を備えた新鮮なエージェントをタスクごとにディスパッチする。
仕様が精密だと、計画もその精密さを継承し、サブエージェントもさらにそれを継承する。統合段階でのリワークはほとんど起きませんでした。
驚いたのは、このチェーンが 複数の並列Claude Codeセッション に対しても綺麗に合成できる点です。あるセッションで機能Aをブレストし、別のセッションで機能Bの実装計画を磨き、さらに別のセッションで機能Cの計画をサブエージェントに実行させる。3つが同時に走っても、それぞれのセッションが自分のコミットされたspec/planファイルを参照しているので、互いに踏まない。
docs/superpowers/ 以下のgit管理ツリーは、生きた設計ジャーナルにもなっています。2つPR後に当時の判断を見返したくなったとき、その理由と進化の経緯が、コミット履歴の中にそのまま残っています。
2. 自作の oslog-stream-to-file スキルで、オンデバイスのデバッグループが消えた
このスキルを書く前、iPad固有の挙動をデバッグするフローはこうでした：バグ再現 → XcodeかConsole.appを開く → サブシステムでフィルタ → 該当行をスクショかコピー → Claude Codeに貼り付ける → イテレーション。1サイクルごとに、機械的な翻訳作業に何分も取られていました。
このスキルは、動いているiPadのOSLogの行を /tmp/<repo>.log に直接ストリームして、Claudeが標準の Read ツールで読みます。タイムスタンプも構造化メタデータも保持されるので、僕が手で貼り付けるよりも遥かに豊かなシグナルがClaudeに届きます。
エンジンAの「単語を言う」コーチングを、Claude CodeとiPadだけで、Xcodeを一切ループから外して デバッグした体験は、これまでで一番気持ち良いオンデバイス開発体験でした。superpowers:systematic-debugging との相性が特に良くて、Claudeが仮説を立て、僕に再現を依頼し、生のログを読み、仮説を絞り込む — 僕は一度もウィンドウを切り替えずに済む。
3. Opus 4.7はバルクコンテンツ生成でハルシネーションを起こさない。Sonnet 4.6は起こす
デコーダブル文ライブラリは、各Dayの音素集合に制約された4〜10語の英文を 何千 も必要としました。集合外のグラフィムは1つも許されない。
Sonnet 4.6でプロトタイプしたとき、出力は綺麗に見えるのに、ランタイムのグラフィムフィルタを定期的に通過できませんでした。Sonnetが制約集合外の音素をハルシネートしていたのです。Opus 4.7に切り替えたら、問題は完全に消えました。同じプロンプトが、例外なくフィルタを通過する文を出してくる。
音素グループを横断して、独立したサブエージェントを別々のgit worktreeで並列に走らせた手法は、綺麗に動きました。正直なトレードオフ：このスプリントのために個人でClaude Max 20xプランに加入し、フルスロットルで回したのですが、それでも5時間レートリミットが現実のボトルネックになって、いくつかのバッチは完全並列化を諦めてペース配分するしかなかった。AnthropicとCerebral Valleyが選出参加者に提供してくれた$500分のAPIクレジットが、最悪のタイミングのオーバーフローを救ってくれました。あれが無かったら、ウィンドウのリセット待ちで半日は溶かしていたと思います。
4. frontend-design スキルは、ウェブからiPadへ意外なほど綺麗に移植できる
frontend-design はウェブ／ページ設計向けのスキルとして書かれていますが、その中にエンコードされている原則 — 視覚階層、特徴的なスタイル、プロダクション品質の仕上げ — は、SwiftUIのiPadレイアウト にもそのまま転用できました。ホーム画面、妖怪の週次イントロカード、タイルボードのアクティビティに適用したら、素のSwiftUIパレットから出すよりも明らかに良い出力が返ってきました。
イテレーションループはウェブほど直接的ではありません。各候補状態をスクショして、会話に貼り戻すという手作業が挟まる。「Claude in Chrome」のネイティブアプリ版 — iPadのライブ画面状態をキャプチャして、アプリを自律的に操作できる拡張 — があれば、このギャップは埋まります。それが現れたとき、ソフトウェアエンジニアリング自動化はまた一段、先に進むはずです。
これから
Built with Opus 4.7ハッカソンが終わってさすがに疲れたので、今は活動が疎かになっていますが、 TestFlightのベータテスター を募集しています。とくに歓迎したいのは、L1日本語の子が英語を学んでいるご家庭です（ディスレクシアの診断の有無は問いません）。L1の背景が違うご家庭からの応募もぜひお待ちしています。国際展開の計画は今まさに動き出しているところで、皆さんのフィードバックがそれを形にしていきます。
- TestFlightに登録: https://forms.gle/RNkKsfvh9PSjrys86
- 3分のデモ動画: https://youtu.be/zrsgP30Miqg
- プロジェクトページ: https://www.youtalk.jp/mora/
入選はならなかったですが、彼に届くアプリは作れました。Claude Codeの使い方ももう何段階か先に行けました。大学院生の頃のように寝食を忘れて取り組むことができ、今回参加できて本当に良かったです。