プラズマを研究していた僕が、なぜ1年でAIワークフローを設計しているのか

僕が入った当時は、バックエンドエンジニア向けのオンボーディング資料がまだあまり整っていなくて。代わりに、インターンの先輩エンジニアと一緒に、要件をもとに1からコードを書いていく、というところから始まりました。今振り返ると、よくやったなと思います（笑）。当然1人では無理なので、社内のいろんな人に聞いて回って。結果的にそれで、職場の人間関係にも自然に慣れていった気がします。

それでオンボーディングの最後に、「次の人が使える資料」を自分で作ったんです。ついこの間まで素人だった人間が作ったものなので中身はひどくて、実際に使われることはなかったんですけど（笑）、自分の努力の成果が形として残って、少しは会社に貢献できた気もして、嬉しかったのを覚えています。

その後は、受託案件のプロジェクトに比較的早い段階から携わらせてもらいました。先輩エンジニアと2人で、完成まで半年ほど。要件を整理して、設計して、実装して、というプロジェクトの流れを序盤から一気通貫で経験できたのは大きかったです。

社長と密に関わっていたのは、主にオンボーディングの時期ですね。実は、初めて会社に行った日にいろいろ説明してくれた人が社長だったんですが、僕はそれを知らなくて（笑）。だから最初は「質問したらなんでも答えてくれる、親切なお兄さん」くらいに思っていました。

その流れでオンボーディング中もずっと面倒を見てもらって、PRのレビューも基本的に社長が見てくれていた気がします。当時の僕は出不精で、リモートで働かせてもらうことも多かったんですが、それでも夜中まで根気強くレビューに付き合ってくれたり、「いつでも電話で質問していいよ」と言ってもらえたり。

振り返ると、社長だと知らなかったおかげで、変に構えずに遠慮なく質問できていたのが、結果的に良かったのかもしれません。今考えるとだいぶ不敬ですけど（笑）。

要件をコードに落とすことに、抵抗がなくなったときですね。入ったばかりの頃は本当に右も左もわからなくて、作業指示をもらっても何から手をつけていいのか見当もつかなかったんです。それが経験を積むうちに、タスクを聞いた時点で「何をすべきか」が頭の中で組み立てられるようになってきて。

そうすると余裕が生まれるんですよね。タスクをもらったときに、方針や実装方法について議論できるようになる。議論の中で先輩エンジニアの考え方に触れられるし、自分の考えもぶつけられる。副次的な効果も含めて、そこが一段成長したと感じたところです。

インターンを続ける中で、心地いい環境だなという感覚はずっとあったんです。それで、本当はそろそろ就活を始めなきゃいけない時期だったんですが、なかなか腰が上がらなくてダラダラしてしまっていて（笑）。ちょうどそのタイミングでmutexから声をかけてもらって、ここだなと。あまり迷いはなかったですね。

博士進学は全く考えなかったです。英語が苦手なので、あの道はちょっと無理だなと（笑）。就活は、mutexの内定がなかったら普通にしていたと思います。だから振り返ると、忘年会帰りの電車での「明日来ない？」がなかったら全く違う人生だったわけで、一期一会だなと感じますね。

医療機関の医事課業務、特にレセプト（診療報酬明細書）まわりの業務を支援するAIプロダクトのバックエンドを担当しています。診療報酬って、点数表や算定ルールが膨大にあって、2年ごとに改定される、日本有数に複雑な制度なんです。医療機関ではその点検業務に、専門知識を持った人が大量の時間を使っている。そこをAIで代替するのがプロダクトの最終目標で、僕もそこに携わっています。

一言でいうと、AIワークフローの設計と実装です。「AIにやらせる」というと簡単そうですが、実際にプロダクトに組み込もうとすると、考えることは多いです。例えばLLMは自然言語処理可能な優秀なツールではあるものの、不確実性があり特に複雑なタスクにおいて精度が落ちます。そうするとタスクの細分化や機械処理の導入をしたくなりますが、それに伴いLLMと機械の役割分担や境界部分の設計が必要になります。

個別のLLM処理についても、データの事前構造化、LLMモデルの選定、ツールの設計、プロンプト作成、性能評価の仕組みづくりとやることは多岐にわたりますね。

不思議な感覚もありますが、振り返ると地続きなんですよね。AIワークフロー設計で問われるのは、実はデータモデリングやAPI設計、テスト設計といったバックエンドの基礎そのもので。LLMが賢くなるほど、差がつくのは周辺のソフトウェア設計なんです。

それと、研究の経験も意外と活きています。シミュレーションコードのデバッグって、出てきた結果から「どこが間違っているか」を仮説検証で突き止める作業なんですが、LLMワークフローの評価やデバッグと同じ頭の使い方なんですよ。プラズマもLLMも、中身を直接覗けない複雑な系を観測から理解するという意味では似ています（笑）。

「複雑なドメインとAIの両方を深く理解して、その間を設計できるエンジニア」です。AIを使えるエンジニアは増えていますが、医療制度のような重いドメインを正確に理解した上で、AIで扱える形に落とし込める人はまだ少ないと思います。ドメインの専門家と同じ言葉で議論できて、それを壊れないシステムに翻訳できる。そこが自分の張っていくポジションだと思っています。

AIの進化速度と、現場の本物の課題が正面衝突しているところです。モデルが数ヶ月単位で賢くなるので、半年前の設計の前提が今日には変わっている。「昨日までAIには無理だったこと」が突然できるようになる瞬間に、本番プロダクトの現場で立ち会える。この設計判断を、意思決定の速いチームでどんどん試せるのが一番面白いです。

入る時点でのスキルよりも、学ぶ意欲がある人なら大丈夫な環境だと思います。少しでも興味があれば、気軽に話を聞きに来てもらえたら嬉しいです。一緒に働ける日を楽しみにしています。