この記事はポエムです。ハッカソンの公式の審査基準を解説するものでも、受賞条件を統計で確かめるものでもありません。募集文と過去の作品を見ながら、ソフトウェアを作る人間の価値がどこへ移っていくのかを考えた記録です。なお、筆者は今回のハッカソンには参加しません。その理由も最後に書きます。
本記事は Claude Code と一緒に作りました。出典の確認と文章の校正にも使っています。内容と結論は筆者のものです。
何を作ってもよいという難しさ
2026年11月に、日本向けのオンラインハッカソン Built with Claude: Japan 2026 が開催されます。募集は選考制で、参加者は最大250人、開発期間は11月2日から10日まで、応募の締め切りは10月26日です。参加の条件は日本在住で、参加者には Claude Max 5x プランと500ドルの API クレジットが提供されます(公式募集ページ、TechnoEdge の記事)。
私は普段、Claude Code を使って、ソフトウェアや AI 関連の研究開発(R&D)をしています。ツールの使い方がわからないわけでも、技術的に何も作れないわけでもありません。それでも「好きなものを作ってください」と言われると、途端にお題が難しくなります。思いついたものは、思いついた瞬間に、もうすべて作ってしまっているからです。
AI エージェント、ロボット制御、シミュレーション、開発基盤。そういうものなら、日常的に作っています。ところが、その延長で何かを作っても、「R&D エンジニアが普段の R&D をやりました」という話にしかなりません。
それで、入賞を狙った場合に評価されるでしょうか。
もっとも、入賞を狙うことが重要だとは思っていません。ハッカソンは、参加することに意味があります。ただ、出るからには入賞したい。その両方が本音です。
この記事では、その問いを、募集文と過去の受賞作から考えていきます。
募集文が先に置いている「作る理由」
主催者の公式募集ページは、興味深い書き方をしています。冒頭で問いかけるのは、モデルの推論性能でもエージェントの構成でもありません。
「こんなツールがあればいいのに」と思ったことはありませんか。
題材の出発点としては、本人が最もよく知る領域から生まれるものと、多くの人を阻んできた壁を取り払うものが挙げられています。さらに、できあがったプロジェクトだけでなく、それを作った人たちも世界に紹介するとしています。
この募集は、誰が、何に困っていて、なぜそれを作るのかを、強く意識させる設計に見えます。「何でもいいから Claude Code で高度なものを作れ」という募集ではなさそうです。
もちろん、「B面を評価する」と公式に宣言しているわけではありません。審査員は近日発表とされていて、審査基準も公開されていません。専門家が仕事上の問題を解くのも、十分に募集の趣旨に合うはずです。ただ、ソフトウェアを開発すること自体が仕事になっている人間には、題材を選ぶうえで別の難しさがあります。
過去の受賞作の主人公
Anthropic が公開した Built with Opus 4.6 の受賞者紹介によると、5人の受賞者のうち4人は、プロのソフトウェア開発者ではありませんでした。弁護士、心臓専門医、道路・インフラ分野の専門家、電子音楽家、そしてプロのソフトウェアエンジニアです。
それぞれの作品には、作った人の具体的な出発点があります。
| 作品 | 作品紹介にある出発点 | できたもの |
|---|---|---|
| CrossBeam | 住宅建築の許認可の手続きが滞っている | 建築図面と修正の指摘を解析し、許認可の対応を支援する |
| PostVisit.ai | 本当に困るのは、診察室を出た後に起きる | 診察の後に、診断の内容の理解を助ける |
| Conductr | Claude を、演奏にあわせて動く仲間にしたい | 演奏にリアルタイムで反応する仮想のバンド仲間 |
| Elisa | 12歳の娘に、Claude Code の端末の画面は向かない | 子どもでも扱える、ブロックを組み合わせる開発環境 |
表は作品紹介の要約です。実際の受賞の理由や、審査の項目そのものではありません。
特に私が唸ったのは、2位の Elisa です。
作者はプロのソフトウェアエンジニアです。それでも作品の主人公は、凄腕のエンジニアである自分ではありません。娘に、理科の自由研究でマイコンを動かさせたい父親です。自分が毎日使っている道具を娘にも使わせたかったけれど、端末の画面は中学生向けにはできていない。だから作った。完成したものを、実際に娘が使ってマイコンにプログラムを書き込んだと、紹介記事は伝えています。
話として強すぎる、というのが私の感想です。父親という立場、目の前にいる利用者、困りごと、解決、使われた結果。この一連の流れが自然につながっていて、後から社会的な意義を付け足した印象がありません。しかも作品は、ブロックを組み合わせてソフトウェアを設計すると、裏で AI が本物のコードを書く開発環境です。ストーリーか技術か、という二者択一ではないのです。
エンジニアの「A面」と「B面」
ここで、仮に本人の顔を二つに分けてみます。
- A面: 職業人としての専門性。私なら、AI やソフトウェアの研究開発エンジニアとしての顔。
- B面: 職業以外の顔。私なら、生活者、趣味人としての顔。
Elisa の作者は、A面の技術力を存分に使いながら、B面で見つけた課題を解決しました。
B面そのものが必須だ、と言いたいわけではありません。医師が医療の現場の課題を解決するなら、A面だけでも相当に強い物語になります。要るのは、その人だから見つけられた課題と、作る必然性です。
ただ、私のようにA面がほぼ「ソフトウェアを作ること」そのものになっていると、A面の課題をそのまま出しても、汎用の開発ツールか、研究開発の延長になりやすい。審査員の目の前で動かしても、「技術的には凄いですね」で終わる危険があります。
だからこそ、B面に目を向ける、という発想が出てきます。
たとえば以前、私は M5Stick で、周囲の Wi-Fi の混み具合を確かめる小さなデバイスを作りました。ドット絵のキャラクターで混み具合を示し、チャンネルごとの込み具合と、いちばん空いているチャンネルを画面に出します。本人にとって現実の不便があり、手の届く技術で解決する。題材の出し方としては、こういうものが近いと思います。
M5Stick で作った、Wi-Fi の混み具合を確かめるデバイス。画面には、チャンネルごとの込み具合と、いちばん空いているチャンネルが出ている
ただ、これだけでは作品として小粒です。地に足のついた問題設定と、人を惹きつける作品としての強さは、別の話です。機能を足して大きくすればよいわけでもありません。そこが難しい。
二つのストーリー
ここまでの話には、二種類のストーリーが混ざっています。
- 作品の説明としてのストーリー: 「この技術によって、こんな社会課題を解決できます」
- 作る必然性としてのストーリー: 「私の目の前にこの問題があり、どうしてもこれが欲しかった」
どちらも大切ですが、後者は、あとから機能を足して作れるものではありません。Elisa が強いのは、後者がそのまま作品の出発点になっているからだと、私は思います。
主催者が題材を促す理由についての仮説
ここからは、Anthropic の事業戦略についての仮説です。
Claude Code の市場を、すでにコードを書く人だけに限る必要はあるでしょうか。
以前、私はGitHub アカウント100万件を無作為に調べた記事を書きました。そこで推計した人数は次のとおりです。
| 指標 | 推計人数 |
|---|---|
| GitHub の個人アカウント | 約2億4,487万人 |
| 直近1年の公開貢献が2回以上 | 約3,298万人 |
| 直近1年の公開貢献が52回以上(週1回相当の「常連」) | 約669万人 |
この669万人は、世界のソフトウェアエンジニアの総数ではありません。GitHub を使わないエンジニアも、非公開のリポジトリだけで仕事をしている人もいます。反対に、GitHub の常連には職業エンジニアではない人もいます。そもそも「年52回以上の公開貢献」は、文字どおり毎週開発したという意味でもありません。
それでも、日常的に公開の場で開発するユーザー層は、世界の人口に比べれば、かなり限られた集団です。
ここから「エンジニア向けの市場はもう飽和した」と言うのは早計です。既存の顧客の利用の増加、企業への導入、API 利用の増加など、成長の余地はいくらでもあります。しかし、非エンジニアに裾野を広げることが、次の大きな市場拡大の経路になる、という推論は自然でしょう。
従来のソフトウェア開発は、課題を持つ専門家がエンジニアに要件を伝え、そのエンジニアが実装する、という分業が基本でした。Claude Code のようなツールがその距離を縮めるなら、医師、音楽家、職人、保護者、地域の活動者などが、自分の問題を自分でソフトウェアに変える世界が広がっていきます。
そう考えると、募集文がモデルの性能の誇示ではなく、「あなたが一番よく知っていること」から始めるよう促すのは、マーケティングとしても理にかなっています。
受賞作品が、技術的に優れているだけでなく、「自分にも作れるかもしれない」と新しい利用者に想像させる事例になれば、Claude Code という製品の市場そのものを広げられます。
ただし、これは募集文と事例からの読み解きです。Anthropic の内部の戦略や、審査の隠れた評価項目を知っているわけではありません。
実装が民主化したあとに希少になるもの
ここまでの話には、少なくとも三つの能力が関わっています。
- 課題を見つける: 現場や生活を深く知っていて、何に困っているかを見抜ける。
- 解決策を実装する: 仕様、コード、テスト、運用を成立させられる。
- 価値を示す: 実際に使ってもらい、何が変わったかを第三者に伝えられる。
従来は、二番目の実装の能力が大きな参入障壁でした。コーディングエージェントによって、その障壁の一部が急速に低くなっています。その結果、一番目と三番目の重要性が、相対的に高まるのではないでしょうか。
もちろん、実装の能力が無価値になったわけではありません。難しいシステムを正しく動かし、安全に保守する能力には、引き続き価値があります。ただ、ハッカソンという短い時間で魅力を伝える場では、「何を作ったか」以前の「なぜ作ったか」が評価を左右する度合いが、以前より大きくなっている気がします。
技術力が十分でも、課題の発見やストーリーの説得力で負ける可能性があります。逆に、ほとんどコードを書いたことのない人が、誰よりも強い題材を持っていることがあります。これは、なかなか皮肉な話です。
筆者が参加しない理由
ここまで、メタ視点からあれこれ考えてきました。
募集文の意図を読み、過去の受賞作品を調べ、GitHub の開発者の人口を持ち出し、ついには Anthropic の市場戦略にまで話を広げました。
では、自分は何を作るのか。思いつきません。
研究開発のエンジニアとして作ってみたいものは、いくらでもあります。しかし、それは普段からやっていることです。今回欲しいのは、技術的に面白いものではなく、「私がこれを作る理由」を、他人にも自然に説明できる題材です。
ところが、胸を張って語れるほど強いB面が、私には見当たりません。ハッカソン向けにもっともらしい社会課題を後付けしたり、無理やり感動的な物語を作ったりするのも、違うでしょう。
参加すること自体に意味がある、という考え方もあります。それでも、出るからには入賞したい。そのための題材が、いまの私にはありません。
したがって、今回のハッカソンには参加できません。少なくとも、今の自分には、納得のいくお題を用意できません。
ここまで Claude Code ハッカソンに必要なことを長々と分析した人間が、最後は、コードを書く前の段階で詰まっています。
Claude Code は、作る能力を拡張してくれます。しかし、作りたい理由まで、代わりに生きてくれるわけではありません。
どうやら私に足りないのは、次世代のコーディングエージェントではなく、自慢できるB面のほうだったようです。