開発速度が100倍になった――AIと共に歩むソロエンジニアの流儀

AIコーディング環境の進化によって、個人エンジニアの開発スタイルは大きく変わりつつあります。今回は、ゲーム開発や医療AI開発を経て、現在は複数のAIプロダクトを1人で開発・運営するソロエンジニアとして活躍される岡本稔さんに、AI時代における個人開発の可能性や、1人で企画・設計・実装・運営まで担う働き方についてお話を伺いました。

岡本 稔(おかもと・みのる)
株式会社AncientTree代表取締役。小学生時代からプログラミングに親しみ、CSK(現SCSK)を経てゲーム業界へ。ハドソンの「ボンバーマン」シリーズやナムコのアーケードゲーム開発に携わった後、体感ゲーム関連事業で起業。その後医療AI分野へ転身し、現在はヘルスケアAIを中心に、企画・設計・実装・運営までを1人で担うソロエンジニアとして大手ヘルスケア企業への提供を含む複数のプロダクトを開発している。

 

ゲームと音楽から始まった開発への目覚め

――本日はよろしくお願いします。岡本さんは小学生の頃からプログラミングに親しまれたとうかがったのですが、やはり入り口はゲームですか?

ゲームと音楽に興味があって、家電量販店のデモを見ながら、自分で作ってみようと思うようになりました。アイデアがどんどんわいてきて、自分で作ってみたら、もっとおもしろいものができるんじゃないか、と思ったのがベースにあったと思います。

――現在は複数のAIプロダクトを1人で開発・運営されているとうかがっています。どのような体制・開発スタイルで仕事をされているのでしょうか?

もともとAIが発達する前から1人でやってきました。最初は東京で就職してシステム開発の部署に配属されたのですが、もともとゲームが好きだったこともあってあまり業務系は向いていないと感じるようになって。それから大手ゲーム会社の下請けで働くようになったのですが、大きな組織では全体の一部しか担当できない。それが窮屈で、次第に「1人で何もかも開発したい」という気持ちが強くなっていきました。これが2度目の転職です。チームで働くのが苦手、というより、自分の作りたいものが作れないことが大きなストレスになってしまうんですよね。

 

健康への関心がAI医療開発へとつながった

――ゲーム開発から、今手掛けていらっしゃるような医療系に移られたわけですが、そのきっかけは?

もともと健康には興味がありまして、最初に立ち上げた会社も健康とゲームを融合したサービスを目指していました。奇遇にもすぐ近くに任天堂からスピンアウトした部隊が体感ゲームを開発していて、銀行の紹介で取引が始まりました。ただ、健康の指標をゲームに落とし込んだだけでは、歩数など単純なものしか表現できないことに限界を感じるようになって、もっと深く医療に踏み込もうと思い、医療系の会社へ就職して修行することにしました。

――AIが登場する前から開発に携わっておられた方にとって、AIの登場というのはどのようなものでしたか?

AIといっても何度かブームがあります。今のブームの1つ前の時期に、ハードウェアでもいける可能性を感じてAIを始めました。その頃は白血病の診断を支援するシステムを担当していて、人間がぱっと見ただけでは判断できないような何十種類もの数値をAIが総合的に判断する、という課題に取り組んでいました。2002年のことです。当時の画像診断はAIが特徴量を抽出してベクトル化し数値に置き換えるものでしたが、今は画像そのものを診断する。基本は同じですが、階層が違います。

 

LLMは「使えるな」

――それからLLMが登場する時代になったのですね。LLMが登場してどうでしたか?

LLMも従来のAIも、それぞれに得意なことと苦手なことがある。「それぞれの長所を組み合わせれば最強になるな」と思いました。手始めに、LLMは汎用的なコーディングが得意なので、自分としてはすごく面倒くさい、それまで触ったことのない言語での開発から実務に取り入れていきました。小見出し)

ハルシネーションを「防ぐ」のではなく「仕組みで抑える」

――LLMというと、ハルシネーションが問題になります。医療系だと致命的ですよね。早い段階からその問題をどうするかについて考えていましたか?

ハルシネーションの問題は早い段階から意識していました。医療系では間違いは許されません。ここでも、さっきの「組み合わせ」が効くんです。エビデンスに基づいたデータだけを裏に持っておいて、LLMはその「語り部」として、エビデンスとなるデータを言語変換する役割で使う、という設計にしています。完全にハルシネーションをなくすことは難しいかもしれない。でも、ハルシネーションを「防ぐ」のではなく、「仕組みで抑える」という発想が重要だと考えています。

――裏に持っておく、というのは、RAGを組み込むということですか?

一般的なRAGは文章の意味を検索して似通ったものを探すシステムですが、それだけだと根拠がどこにあったかわからなくなります。私はRAGとその根拠となる文書をしっかり分けて管理するハイブリッドな手法を取っています。さらに、「血圧が高い」と「塩分の摂りすぎ」のような因果関係を事前にデータに組み込んでおいて、AIが実際の会話の流れの中でもそのロジックを参照しながら答えを組み立てられるようにしています。

――つまり、AIを「なんとなく賢い箱」から、中がよく見えるような仕組みにしようということですね?

そうです。説明可能性をきちんとさせたいんです。AIには昔から「局所解に陥ってしまいやすい」という特徴があります。この範囲の中での最適解はここにしかないからそれを出す、でも本当はその横にもっとよい解があるのに、そこにたどり着けない、というジレンマをずっと感じていて。LLMのハルシネーションも、根は同じだと思うんです。学習していない「空白」の領域に来たとき、モデルは黙ることができず、いちばん近いそれらしい答えを出してしまう。だから、そこに至るロジックや因果関係を明示して、その空白を確かな根拠で埋めていく。完全にはなくせなくても、仕組みで抑えることはできると考えています。

 

AIコーディングで開発速度は「100倍」に

――AIエージェントの登場でエンジニアの在り方みたいなものも変わってきたと思うのですが、実際はどうですか?

確かに、AIコーディングで開発速度は劇的に変わりました。一般的には「数倍」などと言われますが、私の体感では100倍くらい。知らない分野でもまず書籍で調べるプロセスを一気に飛ばせますし、以前はチームで人に任せていた部分もAIが全部やってくれる感じです。

――AIに任せる部分と、自分で書く部分の線引きはどのように?

コード自体は全部AIに任せています。私がやるのは「枠を決める」こと。今はCursorをベースに開発していて、データベースの定義から1つ1つ積み上げていく形でないと、AIが勝手に何でも作ってしまうので。設計のときも、いきなり「こういうの作って」とやると制約なしに作ってしまうことがあります。だからまず、データベースの関係性を定義してから、それをベースに進める。AIがごまかすポイントも大体わかってきたので、必ずその都度テストを行っています。

 

レビューと整合性確認がエンジニアの核心的役割に

――作るというよりも、レビューが重要になってくるわけですね。

そうですね。レビューとテストと動作確認、全体との整合性を確認する、というのが今の私の仕事の核心です。AIの局所解の問題は、どうしてもぶち当たってしまうんです。この課題の中では正解でも、他と合わせたら全然うまくいかない、ということがどうしてもある。そのための補正は必要になってきます。AIが広大な領域をカバーしてくれる一方で、全体を見渡してつなぎ合わせるのは人間の役割です。

 

――逆に、AIの限界についてはどうお考えですか?

限界は、コンセプトや「何のためにこれを使うのか」というマーケティングの部分ではないでしょうか。AIは僕(しもべ)としてはよく働いてくれるのですが、このサービスは何のためにあるのか、というそもそもの部分はAIだと少しずれてしまう。逆に、人間がその部分を制御できないと、見当違いなものができてしまう。今、開発しているシステムでも、AIに広い判断をさせないようにしています。極端に言うと局所的な2択くらいまで解像度を高めて判断させ、それを何段階かの解像度で突き詰めて、1つのシステムを作っていく。今のところ、これが最適解に近いかなと感じています。

 

若手エンジニアへ――「木を見て、森を見る」力を

――これからの若手エンジニアは何を学ぶべきだとお考えですか?

2つあると思います。1つは、物事を構造的に分解すること。「木を見て森を見ず」という言葉がありますが、木を見ながら森を見る、また森を見て木を見る、そういう解像度を常に変えながら見る力を養うことが大切です。

――構造を見極めるのは難しくないですか? 表に出てきませんよね。

確かに表には出てこないのですが、意識して構造を見極める経験を積むことによって見えてきます。AIが作ったブラックボックスでも、システムを考えながら見ると、推測できるようになります。AIに対してそこを突くと、「すいません、やっぱりこうします」と応えてくれる。だから、細部を見る力も、全体を見る力も、両方が重要です。

2つ目は、エンジニア以外のことをエンジニアの視点で見ること。

医療に関わっていると、現行の診断はパターンマッチングの部分が多いんです。エンジニア視点は、構造を全部見ようとする。例えばシステムでエラーが起きても、単純に「これが悪い」とは言えない、さまざまな要素が連鎖しているので、ボトルネックを特定して、全体の因果関係を考える、というのがエンジニア視点です。

こうした視点は、ほかの分野には欠けていることが多い。エンジニアがいろんなジャンルを自分の視点で見ていくことで、今まで不可能だったことができるようになる領域がたくさんあると思います。

 

ソロエンジニアが語る「安定志向」への疑問

――今の学生を見ると大企業志向、安定志向がとても強いように思いますが、岡本さんはどう見ますか?

 

学生の方は大企業の不安定さをまだ知らない、というところが大きいかと思います。実際、大企業に入っても担当できるのは全体の一部分だけ。身につけられるスキルも、外に出たら全く評価されないものが多い。50代になってほかのところでは使い物にならない、というのは、むしろ不安定なことだと思います。

私は20代30代と何度も起業してきましたが、行動したり発信することでリアル・ネットに関係なく繋がりや仲間が増えていき、関わる人が広がると仕事の相手も自然に分散していきます。1人のお客さんが離れてもなんとかなる。大企業だとお客さんは選べない。そのリスクを考えると、絶対に起業のほうが安定すると思うんですよね。さらに言えば、大企業に入ったら、実質的な「お客さん」は上司です。起業すればお客さんは本当の意味でのユーザーです。どちらがやりがいを持って働けるかという違いが大きいと思います。

 

■おすすめの書籍

『失敗をゼロにする 起業のバイブル』中山匡(かんき出版)

1冊挙げるとしたら、中山匡さんの『失敗をゼロにする 起業のバイブル』です。世界中のビジネスモデルを見渡しても、実は数分類の型しかないということを提唱されています。中山さんはエンジニアではないのですが、エンジニアの思考でビジネスを構造化されていて、ケーキ屋さんや弁護士のように自分の能力を提供する型、仲介型、誰かの能力をプロデュースする型などがモデル化されていて、とても参考になりました。この本を読んで、型をいくつも組み合わせることで競合のいない状況が作れる、と気づいて。1つの業態にとらわれず、いろんな角度からビジネスを見る視点が身につきました。

――エンジニアの方が起業の本を勧められるのは、少し意外でした。

私はあまり自分のことをエンジニアだと思っていなくて、プログラムが好きなんじゃなくて、動くものを作るのが好き、役立つものを作るのが好き、というのがベースにあります。そこが一般的なエンジニアと少し違うのかもしれません。だから起業の本もビジネスの本も自然に読みますし、医療の知識もそのまま開発に活きてくる。「エンジニアだからこの領域」という線引きをせずにいることが、ソロで幅広い開発ができる理由の1つかもしれませんね。

 


この記事が気に入ったらいいね!しよう

いいね!するとi:Engineerの最新情報をお届けします

プライバシーマーク