AIの進化が速い。

数日単位で新しいモデルや機能が出てきて、少し目を離すと、前提がすぐに更新される。そんな感覚を持っているエンジニアも多いのではないでしょうか。

ただ、その変化をただ追いかけるだけでは、もう十分ではありません。

今起きているのは、単なる「性能向上」ではなく、エンジニアの役割そのものが変わるような変化です。

最近では、スタンフォード周辺の講義でも、AIの性能そのものだけでなく、それをどう実装し、どう社会の中で使える形にするかという視点が強く語られています。実際の現場でも、議論の中心はそこに移りつつあります。

では、その中でエンジニアに求められるものは何か。

私たちはその変化にどう向き合い、何をつくろうとしているのか。

今回は、プロダクト設計から運用までを見渡しながら、技術を「使える形」に落とし込む立場にある宮崎慧一郎に話を聞きました。

技術の面白さだけでは、プロダクトにはならない

Q. まず、宮崎さんは今どのような立場から技術や開発を見ているのでしょうか。

宮崎：

私は基本的に、プロダクトの設計から実際の運用に落とし込むところまで含めて、どういう構造で業務をプロダクトに落とし込めばいいか、というところを見ています。

単に機能を作るというより、業務そのものをどう整理して、どう設計して、どう仕組みにしていくか、というところですね。

新しいAI技術についても、もちろん技術自体の面白さはあります。

ただ、私が中心に見ているのは、それを実際にプロダクトへどう落とし込めるか、実務の中でどう使えるか、という点です。

どれだけ技術として面白くても、それがプロダクトとして意味があるのか、解くべき課題に対して本当に価値があるのか、という視点がないと、実際のプロダクトにはつながりません。

なので、まずそのプロダクトが解決する課題は何なのかを構造化したり、抽象化したりする。

そのうえで、課題の本質と照らし合わせながら、新しい技術をどこにどう使えるのかを考える。基本的にはそういう順番で見ています。

AIはもう十分に賢い。次に問われるのは「どう動くべきか」

Q. 今、AIの議論自体が性能競争から実装・成果重視へ移っている印象があります。この変化をどう見ていますか。

宮崎：

以前は、AIがどれだけ賢くなったか、どれだけ性能が高くなったか、ということ自体が議論の中心でした。

これは言語モデルだけではなくて、画像生成AIや動画生成AIも含めて、AI全体に共通する流れだったと思います。

ただ、いまはモデルの性能そのものが、絶対値としてかなり高くなっています。

もちろん今後も改善は続くと思いますが、以前のように「前より劇的に賢くなった」という変化は、相対的には小さくなってきている。

その中で、次の段階として「そのAIを実際にどう社会実装していくのか」「人間社会の中でどう使えるようにしていくのか」という議論に移ってきていると感じています。

ここで大きいのは、AIの評価の仕方が変わってきたことです。

これまでは「モデルの性能がどれくらい高いか」という評価が中心でしたが、これからは「AIがどう動くべきか」を使う側が定義しないといけない。

ある行動が良いのか悪いのかは、業務によっても違いますし、同じ業務でも会社によって違います。判断軸は一つではありません。

つまり、これからは「どれだけ賢いか」ではなく、「どう動くのが正しいのか」を設計する段階に入っているということです。

そのためには、AIの行動をかなり細かく分解して、どこまでなら良いのか、どこから先は駄目なのかを、人間が評価できる粒度まで言語化する必要がある。

そこが、これからの実装において非常に重要になると思っています。

AIに丸投げする時代ではなく、人間が「構造」をつくる時代へ

Q. それはエンジニアだけではなく、AIを使う側にも求められることなのでしょうか。

宮崎：

そうですね。AIを導入する際に必要なのは、単に「AIに全部任せる」という発想ではないと思っています。

AIがどういう行動をするのかを適切に分解して、その前提となる業務そのものを、より細かく言語化していく必要があります。曖昧さをなるべくなくしていかないと、そもそも評価ができません。

もちろんエンジニアには必要な視点なんですが、それだけではなく、実際に使う側も含めて、ある程度は「どう分解し、どう評価するか」という視点を持つ必要があると思います。

AIに丸投げするのではなく、どう動かすかを人間側が整理する。そこが大前提になってくると思います。

開発の前提を変えたのは、コード生成そのものより「エンジニアの役割の移動」

Q. AIの周辺では、数週間単位、あるいは数日単位で新しい動きが出ています。その中でも、これは開発の前提そのものを変えると感じている動きはありますか。

宮崎：

そうですね。先ほどのお話ともつながるんですけれども、開発の前提を一番大きく変えているのは、人間エンジニアの役割が「コードを書くこと」から、「課題を構造化してプロダクトに落とし込むこと」へ移ってきている点だと思います。

AIは基本的にもうかなり賢くなっていて、人間がある程度曖昧な指示でも、それっぽいものを出してくれるようになっています。ソフトウェアのコードについても同じで、ある程度雑な要求でもそれなりのものが出てきますし、より具体的な要求を出せば、かなり精度の高いものが出てくるようになっています。

もちろん、そのままリリースできる品質に持っていくにはいろいろ難しさがあります。

ただ、少なくともプロトタイプを作るところはかなり速くなっていて、いろんなアイデアを検証して、すぐ実装して、また試す、というサイクルを非常に速く回せるようになっています。

そういう意味で、もう人間がコードを書くこと自体が中心ではなくなってきていて、実際には課題をどう整理して、どう構造化して、それをどうプロダクトに落とし込むか、というところが開発の中心に移ってきている感覚があります。

これからのエンジニアの土台は、「分解し、評価し、学び続ける力」

Q. そうした時代の中で、エンジニアが土台として持つべきものは何だと思いますか。

宮崎：

ベースとしてやはり必要なのは、課題を適切に分解し、構造化し、それを評価・検証する力だと思います。これはかなり抽象的な能力ではあるんですが、今の時代ほど重要になっているものはないと思います。

そのうえで、土台として必要なのはコンピュータサイエンスの基礎です。

データ構造、アルゴリズム、ネットワーク、データベースといった、本当に基礎的な部分ですね。そうした基礎力は、やはり持っておく必要があります。

ただ、今はそれを学ぶ環境も大きく変わっています。

昔のように、本を探して、限られた情報を頼りに時間をかけて学ぶ時代ではありません。

いまは情報にアクセスしやすいだけでなく、AIを使えば、自分にとって理解しやすい形に変換しながら学ぶこともできる。

学習効率はかなり上がっていると思います。

だからこそ、これからの時代により重要になるのは、知識をすでに持っているかどうか以上に、学習意欲があるかどうかです。

いまは、学び続ける意思さえあればかなり適応しやすい時代ですし、そこに向き合える人は強いと思います。

JClawが向き合うのは、「便利なAI」の先にある企業の業務そのもの

Q. その中で、私たちの会社としては、どこに可能性を見ているのでしょうか。いま進めているJClawは、どのような役割を担っていくのでしょうか。

宮崎：

J Clawは、AIが業務で使う情報を賢く選別・圧縮する「オーケストレーション層」制御基盤です。用途に応じた機能パック（Pack）を自動選択し、必要なスキルを呼び出し、コストを大幅に削減しながら、企業のルールや予算内でAIを安定稼働させる「AIの司令塔」です。

大きな流れとして、AIは「答えるもの」から「動くもの」へ移ってきています。今でもChatGPTやClaudeのようなサービスを使えば、かなり適切に答えてくれますし、外部アプリケーションと連携して、何かしらの作業を実行させることもできるようになっています。

ただ、現状それらはかなり汎用的なもので、どちらかというと個人利用に寄ったものが多い。私たちが見ているのは、その先です。つまり、企業の具体的な業務を、どうすればAIエージェントとして自動化できるのか。そのための仕組みを、企業向けにどう提供していくかというところに可能性を見ています。

JClawは、そのためのプロダクトです。エンタープライズ向けに、AIエージェントを作るための仕組みを提供しようとしている。単なる汎用AIではなく、企業の実際の業務をどう自動化するかに特化したものです。

ここで重要なのが、最近話題に上がることも多いOpenClawのような流れです。

OpenClawも、AIエージェントを作る方向のプロジェクトではありますが、AIに自由度を与えれば与えるほど、できることの幅は広がる一方で、「何をするかわからなくなる」という問題も大きくなります。

やってほしいことだけではなく、やってほしくないことまでやってしまう可能性がある。

その中で今、かなり重要になってきている考え方が、ハーネスエンジニアリングです。ハーネスというのは馬の手綱のようなものですが、AIの振る舞いを制御するレイヤーを持って、どこまでなら動いてよくて、どこから先は駄目なのかを設計していく。

エンタープライズでAIを使う以上、そこは非常に重要になります。

JClawも、その考え方の上に立っています。

単に「自由にエージェントを作れます」というものではなく、企業の業務を分解し、ドメイン知識も踏まえたうえで、あらかじめ業務ごとのパックのような形にして提供していく。本来、業務をエージェント化するのはかなり高度なことです。業務知識も必要ですし、AIの振る舞いも厳密に定める必要がある。だから「自由に作っていいですよ」と言われても、簡単にはできません。

だからこそ、専門家と一緒に業務パックを設計して、それを使える形で提供する。そういう意味でJClawは、エンタープライズ向けに、あらかじめセットされたエージェントを作るための仕組みになっていくと考えています。

求めているのは、「コードを書く人」より「構造をつくれる人」

Q. そうした動きをしている私たちの会社の中で、どんなタイプのエンジニアが力を発揮しやすいと思いますか。

宮崎：

これも先ほどの話とつながるんですが、いまはプログラムを行動レベルで実装すること自体は、かなりAIが担える時代になってきています。

だからこそ必要なのは、問題そのものを整理して、構造化して、実際の仕組みに落とし込める人です。

たとえば、業務がどういうフローで進んでいるのかを具体的に言語化して、それを構造として捉えられる人。

さらに、新しい技術が次々に出てくる中で、どの技術ならプロダクトに使えるのかを見抜ける人。

何が面白いかではなく、何が使えるのか、何が価値につながるのかを考え続けられる人が強いと思います。

いかに物事を抽象化できるか、という話ではあるんですけれども、抽象化したうえで、それをどう具体化するかまで考えられる人が向いていると思います。

その抽象と具体を行き来しながら物事を考えられる人は、今の環境だとかなり力を発揮しやすいと思います。

正解がないからこそ、試せる。だから面白い

Q. 最後に、私たちの会社でエンジニアとして働く魅力をどう捉えていますか。

宮崎：

これはある意味でトレードオフでもあるんですが、今の時代は本当に正解がないんです。

1か月先に何が起きているかも読みづらい。それくらい不確実性が高い。

ただ逆に言えば、仮説を立てて試して、駄目だったらまた違うものを試す、ということを自然にできる環境でもあります。

正解がないからこそ、決められた答えをなぞるのではなく、新しいことを試すこと自体に意味がある。思いついたことをどんどん試せる現場ではあると思います。

もう一つ強調したいのは、いまはあらゆる学習コストが下がっているということです。

今この瞬間に知らないことがあったとしても、それ自体は大きな問題ではありません。基礎知識が不足していたとしても、学んでキャッチアップしやすい時代です。

大事なのは、「自分には無理だ」と閉じてしまわずに、新しいことに向き合えるかどうかです。

学習意欲を持って、変化の中に入っていける人にとっては、かなり面白い環境だと思います。