AI時代に活躍するエンジニアは、
どんなキャリアを歩んできたのか

第1章 AIエージェントとの協業を支える「タスクゼロ」

── 遠藤さんの自己紹介をお願いします。

ジェネラティブエージェンツでプログラマをしている遠藤大介（えんどうひろかつ）です。2025年7月にジョインしました。

これまで、ガラケー向けサービスの開発やインフラ、新規事業など、さまざまなソフトウェア開発に携わってきました。現在は、AIエージェントとの協業を支えるプラットフォーム「タスクゼロ」の開発を担当しています。

── そのプラットフォームは、どのような役割を担うのでしょうか。

近年はClaude CodeやCodexといったAIエージェントがソフトウェアの開発現場で使われていますが、多くは個人のマシン上で動かすことを前提としています。

一方、ジェネラティブエージェンツが目指しているのは、 仕事の最初の受け手としてAIが動く世界 です。

例えば、メールや問い合わせフォームから届いた情報をAIが受け取り、重要な情報を整理し、人にしかできない判断や対応が求められる段階で「ここから先をお願いします」と引き渡す。そんな流れを実現したいと考えています。

そのためには、AIが人のパソコンの中だけで動いていては不十分です。人がPCを閉じている間もクラウド上で24時間稼働し、外部から届く情報を受け取り、状況に応じて社内情報を参照できなければなりません。

問い合わせ対応であれば、相手が過去に接点のあった企業なのか、同じ企業の別部署なのかといった情報を社内データと突き合わせた上で、人に渡してくれたほうが使いやすい。

AIエージェントがこのような処理を担うには、情報を安全に保存して必要な時に取り出せる基盤が欠かせません。

タスクゼロは、まさにそのためのプラットフォームです。

ジェネラティブエージェンツでは、この基盤だけでなく、その上で動くAIエージェントも自社で開発しています。既存のツールを使うだけでは、業務ごとに必要な柔軟性や制約を十分に設計できない場面があったからです。

その頃、私たちはClaude Codeを活用し、社内業務の一部をAIに担わせる試行を重ねていました。ただ、それだけでは業務ごとに求められる柔軟性や制約を解決できず、細かな要件に応えきれなかった。そこで、西見がタスクゼロ上で動くエージェントもゼロから作り始めたんです。

現時点ではまだ顧客提供前の段階ですが、社内でトライアンドエラーとピボットを重ねながらAIエージェントとの協業を実現するために基盤を磨き続けています。

第2章 プログラミングとの出会いは小学生時代

── 遠藤さんは小学生の頃からプログラミングに惹かれていたそうですね。

小学3年生の頃、父が持っていたNEC製のパソコン「PC-6001」に触れたのがきっかけでした。キーボードが本体になっていてテレビに繋いで使う、その頃でも古い機種です。

電源を入れると、画面にはよく分からない文字列が並ぶ。当時の私にとって、機械といえばファミコンや電卓のように「使うもの」でした。それが、PC-6001では簡単な計算式を書くだけで答えが返ってくる。

「ここにやりたいことを書いたら動くんだ」 と純粋に不思議でしたね。

── その後もずっとパソコンに触れていたのでしょうか。

私の小学生時代はまだインターネットが身近ではなく、自宅にもありませんでした。図書館でBASICの本を借りてプログラムを片っ端から打ち込み、どう動くのかを試していました。

プログラムを書くこと自体が面白くて、画面に線や点を描くだけでも楽しかった。

もともと工作も好きでした。TAMIYAの工作キットでリモコンとモーターを繋いで動くものを作ったり、段ボールやボール紙でいろんなものを作ったりしていました。

プログラムに出会った時 「工作と違って、電気があれば、材料費をかけずに無限にものづくりができる」 と感じたんです。小学校の卒業文集にも「将来の夢はプログラマー」と書いていましたね。

中学生になるとパソコン部に入り、初めてWindowsを知りました。それまで文字中心の画面しか見ていなかったため、グラフィカルな画面を見て驚きました。

ちょうど父が富士通のFMVを買ったこともあり「パソコンはこんなこともできるのか」と世界が広がった。

── ご自身でもパソコンを買ったのでしょうか。

買ったというより、高校生になってから自作しました。パソコンが高かったから、秋葉原でパーツを買い集めてプラモデルのように組み立てたんです。

当時はハードウェアや電子回路にも強く惹かれていたため、ソフトウェアとハードウェアのどちらも学べる高校に進みました。ハードウェアの世界も面白かったものの、学ぶにつれて交流回路に難しさを感じるようになった。直流回路の時はどうすべきかをイメージできていたのに、交流回路を設計するようになった時「自分には向いていないかもしれない」と。

その時、自分はソフトウェアを作るのが好きだったんだと思い出しました。それ以来、進路としてもソフトウェア一筋になりました。

第3章 新卒時、大手を蹴って九州ベンチャーを選ぶ

── エンジニアとしてのキャリアは、どのように始まったのでしょうか。

就職活動は最初から順調だったわけではありません。なかなか内定が出ず、自己分析や面接を重ねる中で、ようやく自分が何を好きで何を語れるのかが見えてきたくらい。

最終的には大手IT企業から内定を頂きました。

ただ、大手企業をゴールにはできませんでした。最終面接で「毎年100人以上の新卒を採用しているが、何をやらせたいのか」と尋ねたところ、返ってきたのは「新卒には特に期待していない」という趣旨の答え。

今、振り返れば当然ですね。新卒がすぐに新規事業を任されるわけではないし、即戦力としてジョインした中途社員が担うことがほとんど。

しかし、そんな環境よりも、 もっと顔の見える距離で仕事がしたかった。

── 「九州のベンチャー」とはどのように巡り合ったのでしょうか。

大学時代、たまたま九州を訪れた際に大雨の被害に遭って復興作業を手伝っていたところ、その会社の人たちと知り合ったんです。「大学でJavaを学んでいる」と話すと「うちもJavaでシステムを作っている」と。

就職活動中にそれを思い出して連絡を取ると、先方も覚えていてくれた。そこで、親の反対を押し切ってその会社に新卒で入社しました。面白そうな方向に流れていった感覚でしたね。

── 実際に入社して、何の開発に携わったのでしょうか。

配属先では、東京の会社と協力しながらガラケー向けの着メロや着うたのサイトを開発しました。

学生時代にもプログラムを書いていましたが、商業システムを作るのは初めて。自分の手元にある端末の上で動くサービスを作れることが純粋に嬉しかったんですよね。

一方、開発に入ると、表から見えているものと裏側の複雑さの差に圧倒されました。キャリアごとに仕様やコンテンツの扱いも一様ではない。しかも、ユーザーにはそうした違いを認識させてはならない。

見た目はシンプルでも、その裏にはかなり重い処理や設計が積み重なっている。商業システムとはこういうものか、と実感しました。

特に印象に残っているのは、高負荷への対応です。ゴールデンタイムにCMが流れると一気にアクセスが集まり、サーバーやデータベースの負荷が跳ね上がる。

ユーザーから見れば、反応が遅ければ不満が出るだけですが、その裏側ではエンジニアが必死に最適化し、落ちない構成を考え続けている。 システムは表から見える以上に重く複雑 なんだと最初の仕事で学びました。

第4章 開発現場の現実と限界、体で思い知る

── 月400〜500時間も働いて、体を壊した時期もあったそうですね。

転機になったのは、ガラケー向け大規模サイトのリプレース案件でした。多くのユーザーを抱えるサービスを別の会社から引き継ぐプロジェクトでしたが、想定以上に難しい案件でした。

問題は、負荷や仕様の見積もりが甘かったこと。既存機能を移植すれば動きそうに見えても高負荷の原因になる処理が多く、仕様は簡単には変えられなかった。成立しているように見えても、実運用に耐えられるのかは別の問題でした。

案の定、運営の切り替えを行った瞬間にサービスは落ち、移管は失敗しました。そこから一度巻き戻し、限られた期間で立て直さなければならなかった。

そんなプロセスから、私は月400〜500時間働くようになりました。終電で帰る途中に呼び戻された日もあり、開発現場は常に緊張状態でした。

この案件を通じてシステム開発の難しさだけでなく、さまざまなレベル感の人が混在するプロジェクトの厳しさも知りました。良い設計ではなくても、何とか動ける状態を優先せざるをえない。見た目には単純でも、実際の運用は多くの人がぎりぎりで支えている。

最終的には体調を崩し、ドクターストップがかかりました。ものづくりを続けるには技術だけでなく、環境やチームのあり方も重要だと考える転機になりました。

── 体調を崩した経験を経て、ものづくりに対する考え方はどのように変わりましたか。

病院のベッドで寝ながら「自分は何をやっているんだろう」と。一方、当時発売されたiPhone 3Gが気になり、その上で動くアプリケーションを作ってみたくなったんです。強制的に立ち止まっても、結局自分は作ることが好きなんだと痛感。

それに、過去の経験を振り返ると、企画する側と作る側が同じ方向を向いていないことも多いと気づいた。企画側はユニークなものを作りたい、開発側は実装の難しさや制約を伝えたい。けれど互いの事情を十分に理解できず、防衛線を張ってしまう。

ビジネスを考える人とエンジニアが同じ課題に向き合えるチームが不可欠だと考えるようになりました。

ただ人数を集めるのではなく、それぞれが専門性を持ち、少数精鋭で動けるほうがいい。そういう環境なら、もっと楽しく、健全にシステムを作れるのではないかと思ったんです。

当時はアジャイル開発への関心が高まっていて、私自身もその影響を受けてビジネス側と開発側が近い距離で動ける少数精鋭のプロジェクトを進めようとしたこともあります。しかし、当時の組織ではその試みは実現しませんでした。

それでも、この時期に固まった 「少数精鋭で、問題に向き合う人たちが一緒に作るべきだ」 という見解は、その後のキャリアの軸になっていきました。

第5章 理想的な開発環境の原型を見つける

── ジェネラティブエージェンツの前に在籍していた企業には、どのような経緯で入社したのでしょうか。

当時、私は「師匠」と呼んで慕っていた先輩と一緒に起業していました。少数精鋭でシステムを作れば体を壊すような地獄を避けられると思いついたから。しかし、東日本大震災の時期と重なって案件がなくなった。

転職を考えていた頃、ガラケー時代の知人からその企業がお客様と二人三脚でソフトウェアをつくっていると聞きました。それはまさに自分がやりたかったことに近かったんです。

ただ、その企業では、私が使っていたものとは違うプログラミング言語がメインでした。それでも入社したかったのは、ビジネスを考える人とエンジニアが二人三脚で進む開発のあり方に惹かれたからです。

ガラケー時代の現場では、サービスインさえできればいいという空気が強く、コードが乱れていても後で何とかすればいい、と考えられがちでした。とはいえ、サービスが始まってからこそ伸ばしていかなければならない。最初の時点で保守しやすい状態にしておかなければ、後で必ず苦しくなる。

私がお世話になった前職は、その点でも私の問題意識と重なっていました。

── 前職で得られたものは何でしょうか。

新規事業には最初から正解の仕様があるわけではない と学んだことです。

入社当初の私は、正しい仕様を引き出し、それを正しく実装すればソフトウェアは上手くいくと想像していました。かと言って、相談に来るお客様の多くは新規事業に取り組みつつ、何を作るべきか自体がまだ定まっていない。つまり、最初から答えがあるわけではなかったんです。

それに気づいてから、ものづくりの捉え方が変わりました。お客様の「こういうことを実現したい」という思いを起点に、どんな形なら使いやすいのか、どんな仕様があり得るのかを一緒に考える。自分が持っている技術スタックや知識、世の中に新しく出てきたものをかき集めて組み合わせながら、ふわっとした構想を形にしていく。

これこそ、私がやりたかったものづくりでした。

さらに、新規事業では一度で正解にたどり着けるとは限りません。最初から完璧なものを作るよりも、試行錯誤しやすい状態を保つことが大切。やってみて「ダメだった」「これも止まった」と経験しながら次に進める。

必要のない機能を増やさず、やらないことを決め、身軽に試せる状態をつくる。その考え方は、ジェネラティブエージェンツでの開発にも繋がっています。

第6章 「コードを書く」から「構成を設計する」へ

── ジェネラティブエージェンツに至るまでのキャリアを振り返ると、どのような道のりだったと思いますか。

「自分が寝食を忘れて取り組めるものは何か」を探し続けてきた道のりでした。私は仕事と趣味をきれいに分けられるタイプではなく、好きだと思えないことも長く続きません。もともとワーカーホリック気味で、1日中プログラミングでものを作っていたいんです。

自分にとって何が楽しくて何が苦しいのかを見極めながらキャリアを歩んできました。

その中で見えてきたのは、自分は新しいテクノロジーを使って新しいソフトウェアを作り続けることが好きだ、ということ。ただ、AIが出てきた時には迷いました。

ソフトウェアでものを作るのが好きなのか、それとも、コードを書くことが好きなのか。コーディングエージェントが一気に普及したことで、その問いを突きつけられたんです。

改めて向き合ってみると、私が本当に好きなのは コードを書く作業ではなく、システム全体の構成を考えて組み立てること だと分かってきました。

コードや構造の美しさを考えるのは好きですし、技術そのものへの関心もある。ただ、一番は、全体をどう設計して形にするのかを考えることでした。

現在、ジェネラティブエージェンツで取り組んでいる仕事は、これまでの延長線上にあります。プラットフォームの基盤も、その上で動くソフトウェアも、AIエージェントも含めて全体を設計できる。AIの力によって、より抽象度の高い構想や設計に集中できるようになって面白さを感じています。

小学生の頃にPC-6001に触れて以来、ガラケー向けサービスの開発も、インフラも、新規事業も経験しました。私は「コードを書く人」というより 「ものを形にするために全体を組み立てる人」 なのでしょうね。今までの人生は、そのことに気づくための旅だったのかもしれません。

(取材・執筆・編集：佐野 桃木)