2026年9月6日(日)に大崎で開催された「The Agentic AI Day」に参加してきました。
この日のテーマは「つくる人が、増えていく。」です。
最初はAIイベントらしいキャッチコピーだと思っていました。ところが、登壇者8人のうち4人はソフトウェアエンジニアを本業としていません。船舶の研究者、営業職、クリエイター、個人事業の経営者。それぞれが「自分で作ったもの」を持って登壇側に回っています。
なぜ、こんなことが起き始めているのか。
その変化を最も明快に説明していたのが、Windows 95などの開発に携わってきた中島聡さんの基調講演でした。
この記事では、中島さんの講演を中心に、**「AIで作る人が増えたとき、エンジニアの仕事はどう変わるのか」**という視点でイベントを振り返ります。
- イベント: The Agentic AI Day
- 主催: 一般社団法人シンギュラリティ・ソサエティ
- 会場: ファインディ株式会社(大崎)
- 開催日: 2026年9月6日(日)
- 開催時間: 13:00〜19:00
- 内容: 講演8本+ネットワーキング
「ここ半年、ほぼコードを書いていない」
基調講演は中島聡さん。
Microsoft本社でWindows 95やInternet Explorer 3.0/4.0の開発に携わり、現在もGraphAIやMulmoCastなどを自分で作っている現役のエンジニアです。
その中島さんが、講演の冒頭でこう話しました。
「ここ半年、ほぼコードを書いていない」
コードを書かなくなったというより、AIに書かせるようになった。思いついたものを、その場で形にできるようになったからです。
中島さん自身、「人生がバイブコーディングになってきた」と話していました。前日の夜にも、誰かに依頼されたわけではない論文を一晩で書き上げたそうです。
この話を聞いて最初に感じたのは、「AIでエンジニアの開発速度が上がった」という話とは少し違う、ということでした。
重要なのは、ソフトウェアを作るためのコストそのものが大きく下がることです。
100万人に使われなくても、ソフトウェアは作れる
これまでソフトウェアは、開発コストが高いからこそ、多くの人に使ってもらう必要がありました。作る前に「これは作る価値があるか」「かけたお金を取り返せるか」を精査する必要があった、ということです。中島さん自身も、昔はちょっと思いついても作るのが大変だから、まずそれを考えていたと話していました。
しかし、AIによって開発コストが極端に下がれば、この前提が崩れます。
中島さんが挙げていたのは、「来週の合宿だけで使う部屋割りアプリ」や「引っ越しの2週間だけ使う荷物管理アプリ」のような例でした。
数人しか使わなくてもいい。2週間後に捨ててもいい。それでも、作るコストがほとんどかからないなら「作った方が早い」が成立します。
つまり、100万人に売るソフトウェアだけではなく、自分や身近な数人のためだけのソフトウェアが大量に生まれるようになります。
質疑応答で出た算数アプリの話も、この変化を分かりやすく表していました。
これまでなら、多くの子どもが使える汎用的な算数アプリを作る必要がありました。しかしAIで簡単に作れるなら、塾の先生が「この子は分数のここでつまずいている」と知った上で、その子が好きなキャラクターを使った専用教材を作れる。
利用者は1人です。
それでも成立する。
中島さんの話を聞いていると、AIによって変わるのは開発速度だけではなく、「どのくらいの人数に使われればソフトウェアを作る価値があるのか」という経済条件そのものなのだと感じました。
作る人がエンジニアだけではなくなる
開発コストがここまで下がると、当然「誰が作るのか」も変わります。
営業、教師、医師、研究者など、これまでソフトウェアを使う側だった人が、自分の現場で必要なものを自分で作るようになる。
これまでなら、
「現場の人が困る」
↓
「要件をエンジニアに伝える」
↓
「エンジニアが設計する」
↓
「エンジニアが作る」
という分業がありました。
AIが入ると、
「現場の人が困る」
↓
「AIに相談する」
↓
「その場で作る」
まで一人で進められるようになります。
質疑応答では、営業職の参加者に対して「どんなアプリが欲しいかを考えなくてもいい。困っていることを言えばいい」という話もありました。
どういう画面にするのか、どんな仕組みにするのかまでAIが一緒に考えるのであれば、非エンジニアに必要なのは必ずしもプログラミング能力ではありません。
自分の現場の問題を深く知っていること。
それ自体が、ソフトウェアを作るための強い専門性になります。
でも、誰でも作れるようになったら危なくないのか
ここからが、個人的にはこの講演で一番面白かった部分です。
たとえば営業担当者がAIに「顧客管理を楽にするツールを作って」と頼み、AIがPythonを書いて本番データベースにつなぐ。
本人はコードを読めない。それでもアプリは動く。
非常に便利ですが、当然リスクもあります。
データを壊すかもしれない。本来見えてはいけない情報を表示するかもしれない。権限を持っていない人が操作できる状態になるかもしれない。
つまり、「動く」と「安全」は別です。
作る人が増えるほど、この問題は大きくなります。
そこで中島さんが提示していたのが「ハーネス」という考え方でした。
AIを止めるのではなく、「ハーネス」を付ける
Harnessは、もともと馬具という意味です。
馬の力を弱めるためではなく、その力を安全に使うための仕組みです。
AI開発でも同じで、AIにコードを書かせること自体を止めるのではありません。むしろ自由に作らせる。
ただし、絶対に破ってはいけないルールだけは、AIが自由に変更できない形で先に固定する。
たとえば、
- 誰がどのデータを見られるのか
- 誰が承認できるのか
- データがどの状態なら更新できるのか
- 絶対に壊してはいけないデータの整合性
といった部分です。
一方で、UIや表示方法などはAIに比較的自由に作らせる。
全部をAIに任せるのでもなく、全部を人間がレビューするのでもありません。
「AIに自由に作らせる領域」と「絶対に守らせる領域」を分ける。
中島さんはClaude Code自体もハーネスの一種で、その上に作られたMulmoClaudeやMulmoTerminalもハーネスだと説明していました。
壊れてはいけないルールは、先に固定する
この話は設計論にもつながります。
中島さんはMVCを例に、UIやビューはAIに自由に作らせてもいい一方、スキーマやビジネスロジックなど、壊れてはいけない部分は宣言的に固定しておくべきだと話していました。
たとえば「経理担当者しか承認できない」というルールがあるとします。
このルールを画面側やコントローラー側だけに書いてしまえば、AIがそこを書き換えたときに、ルールまで壊れる可能性があります。
だから重要な制約は、もっと下のレイヤーで守る。
コントローラーやビューにバグがあっても、データの整合性だけは壊れない。
AIに「間違えないコードを書いてくれ」と期待するのではなく、間違ったコードを書いても致命傷にならない構造を先に作るという考え方です。
この発想は、AI時代の開発でかなり重要になると思いました。
AIのコードを、人間はいつまで全部読むのか
質疑応答では、「AIが生成したコードを人間がレビューしきれない」という話も出ました。
中島さんは、コンパイラが登場した頃の話を例に挙げていました。
昔は「コンパイラが生成した機械語を本当に信用していいのか」と考え、出力された機械語まで確認していた人がいた。しかし今では、毎回コンパイラの出力を確認する人はいません。
AIによるコード生成も、いまはその過渡期なのではないか、という話です。
もちろん現在のAIとコンパイラをそのまま同一視はできませんが、論点は分かりやすいです。
生成されるコード量が増え続けるなら、「全部を人間が読む」を前提にした開発はいずれ限界が来る。
そうなると重要になるのは、AIが書いたコードを全部読む技術ではなく、全部読まなくても安全性を担保できる開発環境を作る技術なのかもしれません。
バイブコーディングを止めるのではなく、安全にする
講演全体を聞いていて感じたのは、方向性が「AI開発を禁止する」ではないことです。
非エンジニアがAIでコードを書くのは危ないから禁止する。
バイブコーディングは品質が悪いから禁止する。
そうではなく、どんどん作らせる。その代わり、壊れてはいけない部分だけをエンジニアが先に守る。
自分なりにこの講演を一文に圧縮すると、
「バイブコーディングを止めるな。ただし、壊れてはいけない部分だけはエンジニアが先に囲え」
という話だったと思います。
講演で語られた世界は、すでに登壇者席にいた
そして午後の登壇者を見ると、中島さんが話していた「作る人が増える世界」は未来予測だけではありませんでした。
この日の登壇者8人のうち4人は、ソフトウェアエンジニアを本業としていない人たちです。
| 登壇者 | 本業 | 作ったもの |
|---|---|---|
| 藤井迪生さん | 船舶運航の独立研究者(博士・一級海技士) | 船上のヒヤリハット・事故分析ツール。タンカー110隻で実証実験へ |
| 安宅滉貴さん | 求人サービスの営業職 | 業務画面で動く自作スクリプトで手作業を削減 |
| クリエイター上杉さん | クリエイター | 名刺トレカ・農業支援・日本酒・思い出を残すサービス |
| 髙橋祐樹さん | 個人事業20年の経営者 | 外注していた仕事をAIエージェントに置き換え |
4人に共通しているのは、自分の現場の道具を自分で作っていることです。
船の事故分析ツールを作ったのは、船の現場を知り尽くしている研究者。業務画面のスクリプトを書いたのは、その画面を毎日使っている営業担当者です。
この4人は全員、自分の作ったものを持って登壇者席に座っています。
この光景自体が、「つくる人が、増えていく。」というテーマを一番分かりやすく表していました。
エンジニア側も「実際に動いているもの」を持っていた
もちろん、エンジニア側の登壇者も印象的でした。
有本勇さんは2020年から毎年異なる領域のプロトタイプを作り続け、SlashGPT、GraphAI、MulmoCast、MulmoClaude/MulmoTerminalへと開発を広げています。「毎年違う領域でひとつ作る」を6年続けている人の話は、それ自体が「作るコストが下がった世界」の実演で、個人的には中島さんの講演と並んで印象に残りました。
森本さんは、AI電話エージェント「nocall.ai」で月間数万件のコールを処理する本番システムを3年間運用しています。
AIイベントでは「こんなことができそう」という未来の話になりがちですが、この日は非エンジニア側もエンジニア側も、すでに動いているものを持っている人が多かったのが印象に残っています。
専門性は消えるのではなく、境界線が低くなる
イベントを通して、「AIによって専門職が不要になる」という印象は受けませんでした。
むしろ逆です。
船の現場を知っている人だから、船の事故分析ツールを作れる。営業担当者だから、毎日の業務のどこが無駄なのか分かる。個人事業の経営者だから、外注していた仕事のどこを置き換えられるのか分かる。
AIがコードを書く部分を補ってくれることで、専門知識を持つ人が自分の専門領域の外側まで手を伸ばせるようになる。
専門分野の壁がなくなるというより、壁が自分で越えられる高さまで低くなるという感覚に近いです。
イベントページにあった「人間の専門性そのものが、再構成されようとしている」という言葉は、こういう意味なのだと思いました。
では、エンジニアの仕事はどう変わるのか
ここが、今回のイベントで自分が一番持ち帰った部分です。
AIによって、エンジニアがコードを書く時間は減るかもしれません。
しかし、エンジニアが不要になるというより、責任を持つ範囲が変わっていくように感じました。
これまでエンジニアが「正しいコードを書く人」だったとすれば、これからは、
「誰がAIでコードを書いても、大事故にならない環境を作る人」
という役割が大きくなる。
具体的には、AIが触っていい範囲を決める。権限やデータ構造を守る。破ってはいけないビジネスルールを固定する。自動テストや検証の仕組みを作る。非エンジニアでも安全にAIを使える基盤を用意する。
生成されたコードを毎回1行ずつ読むのではなく、そもそも間違ったコードが致命傷にならない構造を先に作る。
中島さんの「ハーネス」の話は、その役割をかなり具体的に示していたと思います。
支えていた人たち
ここまで講演内容を中心に書いてきましたが、最後にイベントを支えていた人たちにも触れておきます。
会場を提供したのはファインディ株式会社です。
「挑戦するエンジニアのプラットフォームをつくる。」をビジョンに掲げ、エンジニアと企業のマッチングサービス「Findy」のほか、開発ツールを利用企業のレビューから比較できる「Findy Tools」や、テックカンファレンスに特化した「Findy Conference」を提供しています。
今回も大崎のオフィスが会場となり、冒頭では同社の山本さんによるスポンサーLTもありました。
後援はDevX/Raycast Community Japan。
Developer eXperienceに関心を持つエンジニア、デザイナー、ビジネス職で構成されたボランティアチームで、海外のDevXツールを日本に紹介する活動や、ランチャーアプリRaycastの日本ユーザーコミュニティ「Raycast Community Japan」の企画運営を行っています。
登壇者が主役のイベントですが、こうした会場提供や運営の支えがあって、参加無料でこの規模のイベントが成立していました。
まとめ
「つくる人が、増えていく。」
参加前は、AIイベントらしいキャッチコピーだと思っていました。
しかし一日を通して見ると、かなり具体的な変化を表した言葉でした。
AIによってソフトウェアを作るコストが下がる。すると、数人しか使わないアプリや、たった一人のためのアプリまで作れるようになる。
その結果、船の研究者、営業職、個人事業の経営者など、これまでソフトウェアを「使う側」だった人たちが、自分の専門知識とAIを組み合わせて「作る側」に回り始める。
そして作る人が増えるほど、今度は**「安全に作れる環境を誰が用意するのか」**という問題が大きくなります。
そこで必要になるのが、中島さんの講演で語られた「ハーネス」という考え方です。
AIにすべてを任せるわけでもない。AIが書いたコードをすべて人間が確認するわけでもない。
自由に作らせながら、壊れてはいけない部分だけは先に守る。
今回のイベントを通して、エンジニアの仕事は「コードを書くこと」から、その外側へ広がっていくのだと感じました。
数年前なら客席にいたかもしれない人たちが、すでに登壇側に回っています。
「つくる人が、増えていく。」は、これから起きる話ではなく、もう始まっている話でした。