クライアントの業務を理解すれば、「本当に必要なもの」が見えてくる。

不動産企業のDX内製化エンジニアとして従事した後、JDSCに入社。現在はFDE(Forward Deployed Engineer)として海事向け「AI番頭」をはじめとするAIエージェントの開発や実装プロジェクトに携わる。

AIを使ったシステム開発に興味をもちJDSCに参画。クライアントの内側から技術提案。   

―JDSCに入社するまでの経緯を教えてください。  

以前は不動産会社でエンジニアとして働いていました。主に担当していたのはDXの内製化に関する業務です。当時から、ウェブアプリケーションのみだとできることに限界があると感じていまして、「AIを使ったらどんなことができるんだろう」となんとなく考えていました。そんなとき、JDSCの社員とお話する機会があり、AIを組み込みながらシステム開発をすることに興味を持ち、また、選考中も採用担当の方含め面白い方にたくさんお会いし、入社することを決めました。 

―現在JDSCではどのような業務を担当しているのでしょうか。 

FDE（Forward Deployed Engineer）としてクライアントと直接連携しながら、業務理解から提案・実装までを担っています。また、Tech Leadとしてアーキテクチャ設計や開発方針の策定にも関わり、プロジェクト全体の技術的な意思決定をリードしています。 

具体的なプロジェクトとしては、海事領域のAIエージェント「AI番頭」があります。これは、経産省とNEDOが主催する生成AI プロジェクト「GENIAC（Generative AI Accelerator Challenge）」の GENIAC-PRIZE で、カスタマーサポートの生産性向上領域の第2位（懸賞金4,000万円）を獲得しました。 最終審査会場での表彰式で、審査員のお一人である東京大学の松尾豊教授に、「専門性の高い領域でお手本のようなAIの使い方だった」と仰っていただけた事例です。 どんなソリューションかと言うと、海事特有のニーズや困りごとをヒアリングし、生のデータを見て、テクノロジーに基づいてクライアントの業務改善を支援します。スキャンされた契約書のPDFを正確に読み解けるよう画像処理を行ったりAIの解釈を取り入れたりと、現場の業務に直接的に関わる課題解決を行っています。船舶関連の契約書は、見出しのフォントが特殊だったり、契約書に取り消し線があったり、付帯文書が幾つも連なっていたりと独特です。マルチエージェントシステムである「AI番頭」は、海事のエキスパートとして、検索のモジュールや過去の履歴といったナレッジデータを基に意思決定を計画するエージェントを動かすことをミッションとしています。ユーザーである船主の方は、「この荷物を積んでEUに入る時に注意することは？」と都度確認する必要がありますが、従来は膨大な関連文書を調べたり商社に問い合わせたりしていたところ、AIエージェントがメールや複雑な契約書の内容から国際規約、国内規約、除外条件などを考慮して必要な情報とオペレーションを回答してくれます。 

AIエージェントの構築には、「業務理解・意思決定の構造化・データ設計」が不可欠 

―その他にはどういったプロジェクトを担当していますか。

ある大手通信企業様のプロジェクトでは、モバイル端末の営業依頼から申込書を作るプロセスを構築しました。大企業にはさまざまな社内システムがあり、行ったり来たりしながら情報を集めなくてはなりません。また、「このクライアントには特別な条件を提示する」といった個別の条件も加味してDX化を行いました。「こういうケースがきたらこうする」といったデータになっていない要素をデータに置き換えてAIに解釈させ、出力させるという、複数の技術を組み合わせた事例でした。 

業務理解はデータの前提であり、同時にデータは業務理解を更新する手段でもあります。この両者を往復しながら構造化していくことが、AIエージェント開発の本質だと考えています。 

さらに重要なのは、このプロセスが技術と切り離せない点です。業務を理解することで扱うべきデータが定まり、データの性質によって実現可能なアプローチが制約され、最終的にそれらを踏まえて技術として実装されます。つまり、業務・データ・技術はそれぞれ独立した要素ではなく、相互に影響し合いながら成立しています。 

実際に、あるプロジェクトでは業務に関する十分な情報が存在しない状態からスタートしました。そのため、申込ファイルや既存データをもとに業務構造を推定し、仮説を立てながら開発を進めました。このようなケースでは、最初から完成形を目指すのではなく、まず動くものを素早く作り、実データで検証しながら改善していきます。仮説に基づいて実装し、結果をもとに修正する。このサイクルを繰り返しながら、業務理解・データ設計・実装の精度を同時に高めていきます。 

クライアントの業務を自動化するだけでなく、業務フロー自体を構築しなおすようなプロジェクトだったわけですが、 AIエージェントを社会実装する際には、まず正しく使える人がいること、そしてそのためにデータが整備されていることが大前提です。両輪が揃ったうえで開発コストに見合う機能と将来のシナリオまで提案して初めて、AIによる価値を提供できるのではないでしょうか。 

技術はあくまでも手段。使われるシーンや将来像までイメージして提案する。 

―開発するだけでなく、作ったものの使われ方や将来まで想定するというスタンスはどこから来ているのでしょうか？ 

かつて学んだ価値観と自身の経験だと思います。前職でお世話になった師匠から「課題解決のためにソフトウェアがあるのであって、逆になってはいけない」と教わりました。その影響を受けてはいるものの、実は過去のプロジェクトでは技術志向に偏り過ぎて失敗してしまった経験があります。 

ですので社内の会議でも、言われたことをうまく開発するのではなく「そもそもどうあるべきか」ということを念頭に置いて議論することを意識しています。AIを使ったソリューションはデータと業務双方の側面とソフトウェアの特性を組み合わせていくものなので、クライアントの業務や使用シーンを理解したうえで提案していきたいと思っています。 

―JDSCの仕事で、印象的なエピソードはありますか？ 

海事向けAIエージェントを元の担当者から引き継いだ時に、今後の進め方を相談したところ「もっと本質と向き合って考えて」と言われてしまったことがあります。技術的な情報を整理して細かい部分まで確認しようとしていたのですが、本当に重要なことを聞けていなかったんですね。「表面的なことではなく本質的なことを捉えなさい」という先輩の教えは、今も残っています。 

またある時は「AIがうまく回っているのは将棋ぐらい」とも言われました。エンジニアとしてはなかなか強烈な表現ですが、要は「人の話や動きに合わせて行動することが大切」ということだと理解しています。我々の業務に照らし合わせれば、クライアントの業務を深く理解し、クライアントに使ってもらってペインを解消するためのソフトウェアを作ること。大切なことを教えていただきました。 

レベルの高いメンバーやクライアントからの刺激で成長を実感。 

―日々の仕事で感じるJDSCの魅力とは何でしょうか。 

一緒に働くメンバーですね。本当に技術レベルが高い方が多いです。データに対する扱い方も総合的に強いです。また、手を挙げればどんどんプロジェクトに参画させてもらえます。世の中の技術進歩も激しいので、エンジニアとして生き残るためには高い技術力が必要ですが、FDEとしてクライアントからも社内メンバーからも、日々やり取りしながら、常に刺激をもらっています。 

―働く環境についてはどのように感じますか？ 

家庭の事情で出社できる日が限られており、大部分をリモートワークにしていますが、会社に相談し、状況に合わせた働き方を柔軟にサポートしてもらっています。 育休を取得した時は、当初1カ月の申請だったものを延長したのですが、その際もスムーズに対応していただきました。子育ても夫婦で協力してできています。 

―今後JDSCで実現したいことはありますか？ 

技術としてLLMは非常に面白いと感じていますが、もともとの自分の軸は「技術そのもの」ではなく「課題をどう解決するか」にあります。 そのため、単に新しい技術を使うのではなく、課題を構造的に捉え、それを解決するために技術力やデータエンジニアリングをどう組み合わせるかを重視しています。 

今後は、こうした課題の構造化からデータ設計、実装までを一貫して行うアプローチをさらに磨き、より複雑な業務に対しても再現性のある形で価値を提供できるようにしていきたいと考えています。 そのうえで、LLMの進化に伴い、マルチエージェントやマルチモーダル、ローカル環境での活用といった形で、扱える問題の幅や実行形態は大きく広がっていくと考えています。 こうした変化に対しても、単に技術を追うのではなく、これまで培ってきた業務理解やデータ設計のアプローチと組み合わせながら、実際の業務に適用できる形に落とし込んでいきたいです。