4/21~4/27でAnthropicのOpus 4.7ハッカソンに参加しました。

私が作ったのは「Misologist」というアプリだ。味噌づくりにおける発酵状態をAIで診断し、職人の経験知を科学的な言葉に変換することを目指したプロダクトである。

私のリポジトリはこちら。

味噌の表面写真をアップロードすると、Claude Opus 4.7がカビの可能性、危険度、発酵の化学的な理由、次に取るべき行動を返す。さらに、味噌のバッチ管理、レシピ管理、伝統的な発酵知識の翻訳機能も実装した。

テーマとしては悪くなかったと思う。

発酵、味噌、職人知識、AIによる診断。
日本らしさもあるし、Visionモデルとの相性もある。
小規模な醸造所や家庭で味噌を作る人にとって、発酵状態の判断は意外と難しい。失敗すれば数ヶ月の仕込みが無駄になる。

しかし、結果として私は上位ファイナリストには選ばれなかった。

そこで、ファイナリストに選ばれたリポジトリと自分のリポジトリを比較し、「なぜ勝てなかったのか」を整理してみた。

今回参考にしたファイナリストのリポジトリは以下。

結論：アプリとしては悪くないが、ハッカソンで勝つ見せ方ではなかった

最初に結論を書くと、Misologistは「普通に便利そうなアプリ」ではあったが、「Opus 4.7だからこそ成立するプロダクト」には見えにくかった。

これはかなり大きい。

ハッカソンでは、単に動くアプリを作るだけでは弱い。
特にAnthropicのOpus 4.7ハッカソンであれば、審査員は当然こう見るはず。

「このプロダクトは、Opus 4.7の能力をどれだけ活かしているのか？」

私のMisologistは、画像診断、化学的説明、レシピ生成、バッチ管理といった機能を持っていた。
しかし、README上では「Claude APIを使った発酵診断アプリ」に見えやすかった。

つまり、こう思われる可能性がある。

「これはGPT-4oでもできそうでは？」
「普通のVisionアプリでは？」
「Opus 4.7である必然性はどこにあるのか？」

ここが弱かった。

ファイナリストのリポジトリは何が強かったのか

ファイナリストのリポジトリを見ていくと、共通点があった。

それは、「一言で価値が伝わる」ことだと思う。

たとえば、https://github.com/leventilo/mobius は「物理論文PDFをアップロードすると、実際の物理モデルに基づいたインタラクティブなシミュレータを生成する」というものだった。

これは強い。

論文を読む。
数式を抽出する。
物理モデルを理解する。
Pythonでソルバーを作る。
実行する。
結果を可視化する。
さらに、科学的に妥当かどうかをチェックする。

ここまで来ると、明らかに単なるチャットボットではない。
Opus 4.7の長文理解、コード生成、ツール使用、検証能力を総動員している。

別のリポジトリ https://github.com/adindamochamad/omnibridge では、レガシーなシリアル通信機器のプロトコルをAIが解析するアプリがあった。
生のバイト列を読み、Claudeがツールを使いながら通信プロトコルを推定する。CRC検証、baud rate探索、デバイスプロファイルの学習まで行う。

これも強い。

なぜなら、「人間のエンジニアが何時間もかけてやっていた解析を、AI agentが短時間で行う」という構図が明確だからだ。

また、https://github.com/Saadzwak/design-office は、オフィス設計を自動化するリポジトリだった。
クライアントのbriefを読み、PDFのフロアプランを解析し、3Dのtest fitを作り、mood boardを生成し、さらにDXFまで出力する。

これも「AIが本当に仕事のワークフローを置き換えている」感がある。

ファイナリストのリポジトリは、単にAIを呼び出すのではなく、AIを中心にした複数ステップの仕事の流れを作っていた。

自分のMisologistに足りなかったもの

Misologistに足りなかったものは、大きく5つある。

1. Opus 4.7でなければならない理由

Misologistでは、Claude Opus 4.7を使って画像診断や知識翻訳をしていた。

しかし、Opus 4.7の特長をプロダクト構造に深く組み込めていなかった。

たとえば、Opus 4.7の強みとして考えられるものには、以下がある。

長いコンテキストを扱える
複数ステップの推論ができる
ツールを使える
画像とテキストを統合して判断できる
agentic workflowを構成できる
複数の専門agentを組み合わせられる
検証やcritic loopを作れる

Misologistは、これらのうち「Vision」と「説明生成」は使っていた。
しかし、「長期的な発酵ログを読み続ける」「複数のagentが診断を検証する」「職人知識を構造化して次回診断に反映する」といったところまでは踏み込めていなかった。

結果として、Opus 4.7の必然性が弱く見えた。

2. エージェント性が弱かった

今のMisologistは、基本的にはオンデマンドAPIに近い。

写真を送る。
メタデータを送る。
Claudeが診断を返す。

これは有用だが、ハッカソンで目立つには少し弱い。

ファイナリストの多くは、AIが自律的に複数のステップを進める構造を持っていた。

たとえば、以下のような流れである。

入力を解析する
不足情報を判断する
ツールを呼び出す
中間結果を検証する
必要なら再実行する
最終成果物を生成する
critic agentが妥当性を確認する

Misologistも、本来はこうできたはず。

たとえば、以下のようなagent構成にできた。

Observer Agent
写真、色、表面状態、容器、日数を観察する
Fermentation Scientist Agent
塩分、温度、麹比率、微生物、発酵化学の観点で解釈する
Craftsman Agent
伝統的な味噌職人の判断基準と照合する
Safety Critic Agent
食品安全上、断定しすぎていないかを検証する
Action Planner Agent
次に取るべき作業を計画する

このような構成にしていれば、「味噌診断アプリ」ではなく「発酵判断を行うAIエージェント」に見えたはず。

3. デモのインパクトが弱かった

ハッカソンでは、デモの体験が非常に重要だ。

審査員はすべてのリポジトリを深く読むわけではない。
短時間で「これはすごい」と思える必要がある。

私のMisologistにはスクリーンショットはあった。
しかし、「動きのある驚き」は弱かった。

たとえば、次のようなデモがあれば、もっと強かったと思う。

サンプル味噌バッチを開く
30日目の写真をアップロードする
AIが「産膜酵母の可能性」「危険度YELLOW」と判断する
60日目の写真を追加する
AIが前回との差分を説明する
職人メモ「少しツンとする匂い」を化学的に解釈する
Safety Criticが「写真だけでは食用可否は断定できない」と補正する
次の作業と再確認日を出す

こういうデモなら、「AIが継続的に発酵を見ている」ことが伝わる。

今のMisologistは、一画面ごとの機能紹介に近かった。
それよりも、1つのバッチが時間とともに変化し、AIが判断を更新していく体験を見せるべきだった。

4. Demo Modeがなかった

ファイナリストのリポジトリには、審査員が実データを持っていなくても試せる仕組みが多かった。

これはかなり重要である。

私のMisologistでも、以下のようなDemo Modeを用意すべきだった。

正常発酵のサンプル
産膜酵母が出たサンプル
青カビ疑いのサンプル
温度管理に失敗したサンプル
塩分不足でリスクが高まったサンプル

「Try Demo Batch」を押すと、写真、温度、日数、麹比率、塩分、職人メモが自動で入り、AIが診断する。

これがあれば、審査員は自分で味噌の写真を用意する必要がない。
すぐにプロダクトの価値を体験できる。

ハッカソンでは、この「すぐ試せる」は想像以上に重要だ。

5. READMEがプロダクト説明であり、ピッチではなかった

自分のREADMEは、機能説明としては丁寧だった。

しかし、ファイナリストのREADMEは、ほぼピッチ資料だった。

冒頭で問題を提示し、なぜ今それが重要なのかを書き、AIがどう解くのかを説明し、技術的にどこが新しいのかを示し、デモ動画やスクリーンショットで一気に納得させる。

つまり、READMEが単なる説明書ではなく、審査員向けの営業資料になっていた。

MisologistのREADMEも、もっとこう書くべきだった。

「味噌蔵には、色、匂い、泡、沈黙から発酵状態を判断できる熟練者がいる。しかし、その知識は言語化されず、若手にもソフトウェアにも継承されにくい。Misologistは、その暗黙知を写真、時系列ログ、職人メモ、発酵化学に分解し、AIが継続的に判断できるようにする。」

この方が、プロダクトの意味がはっきりする。

本当はMisologistのテーマは悪くなかった

誤解しないように書くと、Misologistのテーマ自体は悪くなかったと思っている。

むしろ、以下のような強みがある。

日本らしいテーマで差別化できる
発酵食品という文化的価値がある
職人知識の継承という社会的意義がある
Vision AIとの相性が良い
バッチ管理によって長期agent化しやすい
家庭、小規模醸造所、研究者という対象が明確
食品安全という緊張感がある

問題は、これらを「ハッカソンで勝てる形」に変換しきれていなかったことだ。

単なる便利アプリではなく、もっと強い物語にすべきだった。

たとえば、次のようなコンセプトである。

「Fermentation Twin Agent」

味噌の各バッチに対して、AIが発酵デジタルツインを持つ。
写真、温度、塩分、麹比率、職人メモ、匂いの記述、過去ログを蓄積し、発酵状態を継続的に推定する。

このコンセプトなら、Opus 4.7の長文処理、Vision、agent workflow、記憶、検証能力を自然に使える。

次に作るならどうするか

次回、同じテーマで再挑戦するなら、私はMisologistを次のように作り直す。

1. 冒頭のストーリーを変える

「味噌診断アプリ」ではなく、

「発酵職人の暗黙知を継承するAI」

として見せる。

発酵の世界では、数値化されていない判断が多い。
色、匂い、触感、時間、温度、季節、容器、過去の経験。
それらを統合して判断できる人がいる一方で、その知識はなかなかソフトウェア化されない。

そこにAIを使う意味がある。

2. 単発診断ではなく、時系列診断にする

写真1枚を診断するだけでは弱い。

発酵は時間のプロセスである。
そのため、AIも時間を見なければならない。

day 0、day 7、day 14、day 30、day 60、day 180のように、バッチの履歴を蓄積する。
Claudeは毎回、前回との差分を説明する。

「前回は白い膜状だったが、今回は青緑色の斑点が局所的に増えている」
「保存温度が高いため、通常よりリスクが上がっている」
「塩分濃度が低めなので、再発可能性がある」

こうなると、単なる画像分類ではなくなる。

3. Safety Criticを入れる

食品安全に関わるので、AIが断定しすぎるのは危険である。

だからこそ、診断結果を検証するcritic agentが必要だ。

画像だけで断定していないか
食べられると軽率に言っていないか
塩分や温度条件と矛盾していないか
危険度REDの根拠は十分か
追加観察が必要ではないか

これを入れることで、むしろ安全性がプロダクトの価値になる。

「断定しないAI」
「根拠と不確実性を示すAI」
「食品安全を考慮したAI」

この方向性はかなり重要だと思う。

4. 職人ヒアリング機能を作る

職人知識を本当に扱うなら、AIが職人に質問する機能が必要だ。

たとえば、

「良い香りとは、具体的に何に近いですか？」
「どの段階なら混ぜ込みますか？」
「どの状態なら表面だけ取り除きますか？」
「どの状態なら廃棄しますか？」
「過去に失敗した時、最初の兆候は何でしたか？」

こうした質問によって、曖昧な経験知を構造化する。

そして、次回以降の診断に反映する。

これができると、Misologistは単なる診断アプリではなく、「職人知識の収集・継承システム」になる。

5. 3分動画を最初から作る前提で開発する

ハッカソンでは、最後に動画を作るのでは遅い。

最初から「3分動画でどう見えるか」を考えて開発すべきだった。

動画のシナリオはこうだ。

味噌のバッチを作成する
30日目の写真をアップロードする
AIが異常の可能性を判断する
60日目の写真を追加する
AIが時系列差分を見る
職人メモを入力する
AIが化学的に翻訳する
Safety Criticが診断を補正する
次の作業と再確認日を提示する

これなら、審査員にプロダクトの価値が伝わる。

学んだこと

今回の学びは、ハッカソンでは「何を作ったか」だけでなく、「どう見えるか」が非常に重要だということだ。

もちろん中身は大切だ。
しかし、README、デモ動画、スクリーンショット、サンプルデータ、導入手順、ピッチコピーまで含めてプロダクトである。

特にAIハッカソンでは、以下の問いに答えなければならない。

「なぜ今なのか？」
「なぜこのモデルなのか？」
「なぜAIでなければならないのか？」
「なぜ普通のアプリではダメなのか？」
「なぜ審査員はこれを覚えるべきなのか？」

Misologistは、この問いへの答えがまだ弱かった。

まとめ

私はOpus 4.7ハッカソンで勝てなかった。

理由は、プロダクトのテーマが悪かったからではない。
実装がまったく足りなかったからでもない。

一番の理由は、

「Opus 4.7だからこそ成立する体験」

として見せ切れなかったことだと思う。

Misologistは、発酵診断アプリとしては悪くない。
しかし、ファイナリストと比べると、エージェント性、デモの強さ、検証ループ、ストーリー、READMEのピッチ力が足りなかった。

次に作るなら、私はMisologistをこう作り直す。

「味噌職人の暗黙知を、画像・時系列ログ・職人メモ・発酵化学を統合して継承するAI発酵エージェント」

この方向なら、Opus 4.7の強みをもっと自然に活かせる。

勝てなかったこと自体は残念だ。
ただ、ファイナリストのリポジトリと比較したことで、次に何をすべきかはかなり明確になった。

次は、単に動くアプリではなく、審査員が10秒で価値を理解し、3分で驚き、READMEを読んで「これはOpus 4.7でなければ無理だ」と納得するものを作りたい。