Bill One Engineering UnitのPurchasing Groupでアーキテクトを務める豊田(@helloyuki_)です。今日は業務中に行っているAgentic Codingについて紹介したいと思います。
Agentic Codingとは
「Agentic Coding」という言葉を最近にわかに聞くようになってきました。まずAgentic Codingという言葉が何を指すかを押さえておきましょう。類似する言葉に「Vibe Coding」という言葉がありますが、この言葉とAgentic Codingとを比較しつつ、両者が何ができるのかをまとめた「Vibe Coding vs. Agentic Coding: Fundamentals and Practical Implications of Agentic AI」という論文があります。この論文をヒントに紐解いていきます。
定義
Agentic Codingは要するに、AIエージェント（以下、エージェント）が、自ら計画を立て、人の手助けをそこまで得ずに作業を「自律的に」進行するコーディングスタイルのことを指します。ある程度抽象的なお題が人間からプロンプトで与えられ、その内容をAIが考えます。お題を実装するために必要な手順をいくつか分解して、その分解された手順に従って作業を進めるというところを、エージェント自身が一通り行います。
加えて「自律的」の中には、エージェント自身が過去の経験から自己認識を改め、修正する機能も含んでいます。ソースコードを修正していく過程で得られた知見や失敗を記録したり、エージェントが行った意思決定プロセスをログに残しておき、後から振り返って失敗の糧とできます。
このように、計画し、実行し、実行結果を評価し、評価から修正を加えて課題の完遂までたどり着くというフィールドバックループを通じてエージェントが自律的に動くコーディングスタイルをAgentic Codingと呼びます。
Agentic Codingにおいて人間は、総司令官ないしは現場で指揮をとる上司のような役割のみを果たすことになります。出す指令は抽象的であっても構いません。どこに向かいたいのかをエージェントに伝えるだけで良いのです。そしてエージェントがコーディング作業を終えるのを待ち、出してきた成果物を確認するのみです。粗があった場合に少しだけ人力で直してもよいですし、エージェントにもう一度依頼を出してもよいですが、人が本格的に手を動かすのはその程度になります。
私が先日驚いたのは、「RustでHaskellコンパイラを実装したい」というプロンプトをClaude Codeに渡しただけで、Haskellの仕様書を読み込み始め、その仕様に従ってコンパイラを実装するための計画を出してきた点でした。その後作業させると実際に課題の完遂に向かって実装を自律的に開始し始めたのです。完成までかなり時間がかかりそうでしたので完成までは見届けませんでしたが。[*1]
Vibe Codingとの違い
実のところ最初に世界に衝撃を与えたのはVibe Codingでした。ティム・オライリーが「The End of Programming as We Know It」という記事を書き、プログラミングのパラダイムシフトがこれから起こるということを強調していたことも記憶に新しいです。[*2]ティム・オライリーは単に私たちの仕事のやり方が変わっていくのだということを強調していただけではありますが、一方でVibe Codingのセンセーショナルな成果物がいろいろと見え始めた段階から、SNSなどでは日夜プログラマが自分たちの仕事がなくなるのかどうなのかを議論しているのもまた目にするようになりました。
Vibe Codingとは要するに、人間が自然言語によるプロンプトを記述し、それをLLMに渡して指示を出しながらコーディングを進めていくことを指しています。最近非エンジニアであっても簡単なサービスを実装できてしまうと大きな話題になっていましたが、仮にプログラミングについてそこまで詳しくなかったとしても、自然言語で指示を出しながらコーディングをできるという意味において画期的だったと言えるでしょう。
Vibe Codingが変えたのはプログラミングのパラダイムでした。従来のプログラミングとは、プログラミング言語のシンタックスを覚えてそれを利用することであったり、制御構文やデータ型に気をつけながらコーディングすることでした。つまり、「実現したいこと」という観点から見たときに、自然言語よりもさらに「低レイヤー」な、プログラミング言語特有の事柄に気を配りながら作業を進める必要がありました。しかし、Vibe Codingはそれらをまったく気にする必要がありません。自然言語を通じて意図を説明し、ファイルの置き場やコンポーネントの配置といったアーキテクチャ上の指示出しをし、ときにはデバッグの指示出しをしながら作業を進めるだけです。最終的な成果物が「コード」な点に変わりはありませんが、その成果物を得るまでのアプローチが大きく変わったのです。
LLMの出力するコードは比較的正確であり、コピーアンドペーストをするだけで「結構動く」のも衝撃的でした。仮に誤りがあってエラーが出たとしても、そのエラーの内容をLLMに質問すれば、軌道修正したコードを出してくれます。この作業を繰り返せば、私たちソフトウエアエンジニアのようなプログラミングを本職としない人々であったとしても、自分の好みのツールやサービスを一人で作ることができるようになったのです。
Agentic Codingとは異なり、Vibe Codingの段階では、人間によるプロンプトの入力が都度必要になります。出力されたコードに誤りがあったとしても、LLM側が自分で再度エラーメッセージを読み解き、原因追求をしてコードを修正し、再度コンパイルを回すと言った作業を自律的に行うことはありません。人間が都度作業を指示する必要がありました。人間は副操縦士のような役割を果たしており、人間のコード生成を支援することが目的でした。Agentic Codingはこの部分をすべて自律して取り組みます。
Agentic CodingとVibe Codingは包含関係にあるかもしれません。実際私がAgentic Codingを行っている最中、Vibe Codingをする瞬間に出会うことがありました。エージェントを使っていると、作業を計画しタスクを遂行する序盤のタイミングで「taming」と呼ばれる行為が必要になることがあります（これを日本語に訳して「手懐け」と呼ぶこととします）。手懐けをしている段階では、まさにプロンプトを使ってコーディングを逐一進めるよう指示出しを行うわけですが、その瞬間はVibe Codingを行っています。Agentic CodingとVibe Codingはそういう意味では必ずしも独立した概念ではなく、Agentic CodingはVibe Codingを含むという包含関係なのではないか私は考えています。
Claude Codeとは
定義と機能
「Claude Code」はターミナル上で動作し、対象となるコードベースを理解した上で自然言語による指示に従いながらコーディングを進めるエージェント型のコーディング支援ツールです。
Claude Codeを使うと、例えばある機能を一部実装させたり、テストコードを実装させたり、コミットメッセージを考えたり、あるいはリファクタリングをしたりと、さまざまなコーディング支援を受けることができます。
特徴
Claude Codeが特徴的で注目を集めたのは、まずはこれ自体がCLIツールでありポータブルであるという点でしょう。例えば類似のツールであるClineはVS CodeにプラグインをインストールしてVS Code上で動作させる必要があります。一方でClaude CodeはCLIツールであるため、エディタにプラグインをわざわざ入れなくとも動作します。もちろん後述するようにエディタにうまく統合されたプラグインを入れると開発体験は高まりますが、Neovimのターミナル上から呼び出してAgentic Codingの支援を受けるという使い方をすることもできます。
私自身はNeovimユーザーであるため、このポータブル性に当初から注目していました。リリース直後くらいからNeovimを組み合わせながら使い始めました。そして最近では後述するようにIntelliJ向けにClaude Codeのプラグインが提供されることとなり、いよいよさまざまなエディタ上で動作させられる環境が整ってきました。
しかし今月くらいからClaude Codeの注目が最も高まっている最大の理由は、使い放題の定額プランClaude Maxの登場でしょう。これにより利用者のメンタルモデルが、従来の「効率よくエージェントに指示してできるだけ利用料を抑えよう」から、「使える限り使い倒そう」に変わったという意見を目にするようになりました。近いうちに他社も追従する可能性はありますが（と、記事を書いていたらCursorが定額プランを発表しましたが）、今のところはこの定額プランが注目を集めている状況だと思われます。
IDE（IntelliJ）との統合
Bill OneではKotlinをメイン言語として開発が行われています。KotlinはJetBrainsが主に開発を進めていることもあり、現時点ではIntelliJ以外での快適な開発をあまり期待できません。長らく公式にLanguage Serverを持っていない状態が続いており、事実上他のエディタの利用は困難でした。が、JetBrainsもKotlinの利用シェアを上げていきたいと思ったのか、ついに先日kotlin-lspというLanguage Serverを公式が発表しました。これにより近い将来VS Codeなどで快適な開発を行えるようになっている可能性は高いですが、執筆時点ではまだ難しいです。
IntelliJにはJunieのようなプラグインがあり、それを利用するとエージェントを使ったコーディングを行うことは確かに可能です。しかし、VS CodeやCursorのようなエディタのAIの対応状況と比較すると、正直なところかなり遅れているという印象を持っています。AIによるコーディング支援は1年前くらいから盛り上がっていますが、1年経った今でも満足にコーディング支援を受けられているとは言えないと私は考えています。
ところが最近、Claude CodeがIDEとの統合を進めており、IntelliJ向けのプラグインが用意されました。これが非常によく動作し、いよいよClaude Codeを使った本格的なAgentic Codingを始められるようになったのです。実際に業務利用してみていますが、今のところ辛いポイントもなく快適に利用できています。
Claude CodeとIDEの統合については下記のドキュメントに詳しく記載があります。VS Codeへの対応はもちろんのこと、VS CodeのフォークであるCursorやWindsurfといったツールにも対応しているようです。
IntelliJの場合、次のプラグインをインストールして有効化することで、IntelliJ上にClaudeのアイコンが表示されるようになります。このアイコンを通じてか、もしくは所定のショートカットキーの入力を通じてかのどちらかでClaude Codeを立ち上げることができます。
実務での利用事例
ここからは実際に私が仕事中に試してみた事例を紹介したいと思います。なお、記事にまとめるとすんなりうまくいったように見えるものですが、それなりの時間を使って試行錯誤した結果がここには記載されています。また、Bill One全体がやっている話ではなく、私が手元で個人的に試した話であるという点に留意してください。
何をやらせてみたか
私たちの開発グループでは、バックエンド開発において、あるドメインモデルに対するバリデーションチェック処理で実装が分散している箇所がありました。バリデーションチェック処理の実装が分散していると、もし仮にドメインモデルの不変条件に対して変更を加えた際や新たな不変条件を追加した際に、設計上任意の値を入れられる構造になっていました。
通常の利用においてはフロントエンド側でのチェックによりこの問題は防げていましたが、より堅牢な設計を目指し、ドメインモデルが本来守るべき不変条件を確実に保証させるために、「Parse, don’t validate」と呼ばれる関数型プログラミングの界隈では昔から言及される原則に従って実装を直していこうと考えました。具体的には次のように、「空でない文字列のみ保持できる型」を用意したり、「空白文字などが確実にカットされた値のみ持つことができる型」を用意するなどです。
@JvmInline value class NonEmptyString private constructor(val value: String) { init { require(value.isNotEmpty()) { "value must not be empty" } } companion object { fun of(value: String): NonEmptyString = NonEmptyString(value) } }
そして、これらの型をいわゆるValue Objectに適用していくという作業が次に発生します。しかしこの修正を入れるとそれなりに影響範囲は大きく、人手でやるとおそらく4〜8時間程度はかかってしまいそうな修正量が見込まれました。
私はここでAgentic Codingを試すいい機会だと思い、Claude Codeを起動して作業をさせてみました。
どうやったか
ドメインモデルの不変条件を示す型は人手で用意しておきました。簡単なデータ構造であるためエージェントにコードを書かせる必要はないのと、実装のデザインは自分でコントロールしたいと考えたためです。
また、Value Objectに対して用意するコンストラクタ関数の実装もひとつだけ人手で実装しておきました。 fromString のような関数を用意したわけですが、これをサンプルとしてひとつだけ人力で用意しておいたのです。Agentic Codingの場面では、あとはこれを横展開してもらうだけの状況を作りました。
@JvmInline value class InvoiceVendor private constructor(val value: NonEmptyString) { init { // この型用の制約条件 } companion object { // Stringを受け取り、内部でNonEmptyStringに変換するためのコンストラクタを用意しておく。 // 空文字列を与えると、内部でrequireの制約条件違反の例外が投げられる。 fun fromString(value: String): InvoiceVendor = InvoiceVendor(NonEmptyString.of(value)) } }
修正前のコードベースでは、直接コンストラクタを経由してValue Objectを生成させていました。しかし今回、 String から NonEmptyString などの独自の文字列型に切り替えた関係で、コンストラクタを経由してValue Objectを生成させてしまうと、型の不一致が理由でコンパイルエラーとなります。これが自動テスト側も含めてかなりの箇所に発生することが事前にわかっていたので、ここをAgentic Codingさせようと考えました。
Claude Codeには次のように指示を与えました。
- まず対象となる各Value Objectに、コンストラクタ関数を生やす。
- 次にコンパイルを一度回し、コンパイルエラーの箇所を確認する。
- 内容を読み解いて、コンストラクタ関数を利用するように直す。
- 2と3を繰り返す。
正直なところ、この指示方法に行き着くまでには少し試行錯誤がありました。エージェントにざっくりした抽象的なお題を与えたとしても当初はなかなかうまくいかず、対象となるコードを絞ったり（探索空間を絞る、とでも言いますか）、あとは横展開するだけの状況に持っていけるよう自身のタスクを調整するなどの工夫をしました。後述するようにPlan Modeを利用するように切り替えたのも成功の要因になりました。
指示を与えた後は、しばらく実際にエージェントが思った通りにコードを直していくかを見守る作業をしました。というのも、ここまで絞ったとしても単純なgrepコマンドをうまく実行できなくてハマったり、変なファイルを読み出すなどの動きをすることがあったからです。そうした妙な動きをした際には、「そうではない、こうしてくれ」という指示を都度与える必要があります。私はこれを「手懐けるフェーズ」と呼んでいますが、エージェントの動作が温まって軌道に乗るまで少しお世話をする必要があります。軌道に乗ったタイミングで、あとは自動モードに切り替えて作業が終わるのを待ちます。
学んだこと
次に実務での利用を通じて学んだことをまとめます。
探索空間を絞る
エージェントが探索しなければならない空間（探索空間）を絞っていくように指示出ししていくといろいろとうまくいくことがわかりました。最初に曖昧な指示を出しつつも、時々エージェントの作業を中断させて、徐々に具体的で細かな粒度のタスクにこちらで分解して指示を出し直すと、作業の精度がだんだんと向上することがわかりました。
重要だと思ったことのひとつとして、タスクを「横展開するだけ」の状態に持っていくことが挙げられます。これは探索空間を絞る行為の一つです。日々の開発において「あとは横展開するだけだ」の展開に突入することが多くあるでしょう。あれです。エージェントの方が人間よりもタイピングがとても速い関係で、横展開はエージェントだとさすがに超高速です。
またこれまでの私の経験的には、横展開の段階にできれば比較的安心して手放せることが多かったです。横展開になったタイミングでバックグラウンドでClaude Codeに作業させて、あとは別の作業に自分は移るといった開発スタイルをとることができるようになります。
Plan Modeは積極的に利用する
Plan Modeとはエージェントに自身が実行しようとするタスクの計画を立ててもらう機能です。かなり抽象的なお題を投げたとしても、Plan Modeを使うと具体的にどのように実装していくかの計画のレベルまで落としてくれ、指示を出す私たちは作業の手順で進めて問題ないかを立ち止まって確認できます。
このPlan Modeは、よほど単純なタスクではない限り十分に活用した方がよいと思いました。私も最初はいきなりClaude Codeにコーディングを依頼していたのですが、そうするとあらぬ方向にどんどん進んでいってしまうことがありました。Plan Modeを最初に挟んでおくと、最初にエージェントが何をするかをリストで確認できます。計画に誤りがありそうであれば、事前にこちらで指摘して方向性を変更することができるのです。
Plan Modeは同時におそらくですが、エージェント自身がコードベースへの理解や自身のタスクの理解を深める契機にもなっているようです。私が思うには、Plan Modeを実行してから取り掛かったタスクの方が、よりよい解決策を持ってくることが多かったように思います。
docの整備を進める
エージェントを活用するあらゆる組織で言われていることですが、まずはコードベース上にドキュメントを充実させましょう。コードが何を意味しているかに関するドキュメントはもちろんそうですが、コーディングルールやプロジェクトにおけるコマンドの実行方法、普段使用しているお手製スクリプトなどあれば、それもリポジトリに載せておきます。
Claude Code向けではありませんが、Bill One内にもいくつかそうしたエージェントに指示を与えるドキュメントがあります。ドキュメントをいくつか見ると、普段どういう実装パターンを利用しているかや、どういうレイヤー構成になっているかなどが割と細かく書かれています。
Claude CodeはAgentic Coding中にこうしたドキュメントを参照し、学習してコーディング作業に役立てます。Claudeの公式ドキュメントにも書かれている通り、CLAUDE.mdや.claude配下にメモリ機能のためのドキュメントを充実させておくと、エージェントの力を最大限発揮させられるようになります。
MCPサーバーの活用
エージェントが作業する様子を見ていると、まるでひと昔前のコーダーが仕事を進める様子を見ている気分になることがあります。findを使って手当たり次第にファイルを探しますし、grepを使ってかなりがんばって対象となる関数や変数を見つけているように思うのです。私の好きなストリーマーのYouTube動画に、シンタックスハイライトもLanguage Serverも何も設定していない素のviでLinuxカーネルを開発する動画があるのですが、あれを見ている気分になります。
どうやら、エージェントはコードを探索する際にASTを見ているわけではないようなのです。しかし我々は、普段の開発ではLanguage ServerやIDEが提供するコードジャンプなどを駆使して開発を進めているはずです。grepやfindで時間を余計に使われてしまうと、せっかくAIを使っている旨みがありません。何よりお金を無駄にするかもしれません。
こういうときにMCPサーバーが役に立ってきます。KotlinはIntelliJとよく統合されているので、IntelliJのMCPサーバーを使うと少しだけそちらを使いながら作業してくれ、効率が微妙に上がることがわかりました。ただしどのタイミングであってもIntelliJのMCPサーバーを経由してくれるわけではなく、かなり強めに指示しておかないと慣れたfindやgrepを使い始めてしまうようです。エージェントがきちんとMCPサーバーを優先的に扱う部分は、今後改善されると嬉しいポイントです。
Claude Codeの場合、 .mcp.json というファイルをプロジェクトのルートディレクトリに置くことで、そのプロジェクト内で使用するMCPサーバーを定義できます。たとえばIntelliJのMCPサーバーを利用したい場合、次のように記述すると機能を利用できるようになります。
{ "mcpServers": { "jetbrains": { "command": "npx", "args": ["-y", "@jetbrains/mcp-proxy"] } } }
MCPサーバーとの統合は今後も進んでいくものと思われます。Language ServerをMCPサーバーとして使えるようにしておき、それをエージェントに読ませるコーディングスタイルも今後発展していくのではないかと思っています。findやgrepでファイルやコードを探すより、Language Serverの機能を使ってコードを探す方が速いですからね。
作業が軌道にのるまで「手懐け」
Agentic Codingをしていると、エージェントが温まっていって作業精度が上がる瞬間に出会うことがあるように感じました。エージェントを「手懐ける」フェーズがあるように思うのです。最初から自動承認モードにして放置してうまくいくケースもままありますが、最初の2、3回のやりとりは人間がチェックしておいた方がよいと思っています。私のプロンプトの書き方の問題というのはあるかもしれませんが。
この話を書いていて、最近Zedというテキストエディタを作っている会社が発表していた「Agentic Engineering」という整理がまさにこれをよく説明していると思いました。Agentic Engineeringが示すように、開発支援ツールのアプローチには「traditional」と「emerging」の2つがあります。速くて、信頼性が高く、決定論的で予測可能な成果を得られるtraditionalと、流動的で、確率的で探求的かつ多大なクリエイティビティの可能性を含むemergingという分類です。
これは開発支援ツールに対する分類ではあるのですが、この整理軸は抽象化してAI時代の開発プロセス内の多くの物事に転用可能だと思いました。「決定論的ではあるものの、人力であるためスケールしない」traditionalと、「非決定論的で結果が確率的ではあるものの、非常によくスケールする」emergingと読み替えることもできると私は考えています。
最初に人手でtraditionalなコーディング作業をし、その後たとえば一部の開発をemergingなAIを使った開発に切り替えるというのは、Agentic Engineeringの代表的な方法といえるでしょう。今回私が取り組んだように、人間の手でアーキテクチャの全体観のようなものを作っておき、エージェントにそれを読ませてデザインを横展開させるという方法です。
エージェントとの対話は、探索（emerging）から収束（traditional）へとアクセルとブレーキを切り替えるイメージです。まずはemergingなプロンプトで可能性を広げ、互いにタスクの輪郭を掴みます。手応えが出てきたら、具体的な制約や完成形の条件を追加入力して解空間を絞り込み、決定論的なtraditionalモードへ収束 させる。この「絞り込みフェーズ」を支えるのがPlan Modeです。絞り込む瞬間が、エージェントを手懐ける瞬間です。
Bill OneでのAI駆動開発
Bill Oneでは多くのメンバーがAI駆動開発の探究に取り組んでおり、さまざまな知見が共有されています。そうした知見はSlack上で確認できますし、Notion上には「AIエージェント活用知見データベース」なるページがあり、ここにメンバーによるさまざまな試行が記録されています。
Bill Oneでは現状、次のエージェントやツールが多く使われているようです。
- コーディング支援
- Devin
- Cline
- Cursor
- Claude Code
- GitHub Copilot
- コードレビュー支援
- Qodo Merge
- CodeRabbit
- そのほか
- Claude Action
どのツールに軍配が上がるかはまだまだ判断が難しい状況です。どのツールにもいい点と足りない点があり、日々Slack上では活発にさまざまなツールについて議論が交わされているのを目にします。Bill Oneには主にAIエージェントの活用について模索する専任のチームがあるほか、そうした話題が集約されたSlackチャンネルが用意されており、そこでさまざまな議論が交わされています。
大きくコーディングの速度が上がったと体感できた事例として、これは他チームにヒアリングしたものですが、UIコンポーネントの移行作業をDevinに任せてみたという事例があります。Bill Oneでは現在、Sansanの提供するOneシリーズ向けのデザインシステムに従ったコンポーネントであるOneUIへの置き換え作業が進んでいます。この移行作業にDevinを活用し、実際に作業効率の大幅な向上を体感できたとのことです。
コードレビューでも一定の成果を上げ始めています。Pull Requestを出すとQodo Mergeがコードをレビューし、注意すべきポイントをコメントしてくれます。中には、人間であれば見逃していた、かつ、そのままリリースしていたらインシデントにつながっていたものを事前にQodo Mergeが指摘していたという事例もありました。
Sansan全体としてAIの利活用を推進しているおかげで、私の仕事の仕方にも変化が出つつあります。まずなんとかAIにお願いできないかと考えるようになりましたし、ちょっとした調べごとをする際にもAIと議論を進め、考えを深めることが増えました。エージェントを使ったコーディングもその一環だったと言えるでしょう。ちなみにですが、お気に入りはGeminiです。
まとめ
各社状況は似ていると思いますが、Bill Oneも現在はさまざまなエージェントを試している段階であり、今後開発プロセスにどのように組み込まれてくるかは未知数です。
私の個人的な意見を書いておくと、エージェントが作業を完全に代替することはなく、一部の仕事は引き続き残り続けると思っています。とくに残るのが先ほど説明した「Agentic Engineering」の整理における「traditional」なコーディングスタイルが要求される場面です。今回事例として紹介したように、横展開を開始する前のコードのデザインを決める部分の一部は、引き続き残り続けると思います。しかしやはり今回この記事で示したように、デザインを決め切って横展開するタイミングになれば、「emerging」なコーディングスタイル、すなわちエージェントをフル活用することができるはずです。emergingを上手に活用できる場面を広げていくのが肝になりそうです。
「AI駆動開発」というと、仕事中に出会うすべてのコーディング作業を置き換えられることを期待値としてしまいがちですが、できる場面とできない場面がありそうに見えています。ここは期待値の調整が必要です。もちろん、間違いなく今後数年をかけて劇的に性能は向上していくとは思います。しかし、現段階ではエージェントにすべて開発させることを理想とするのではなく、どの部分をエージェントに確実に任せられそうかをうまく見極めるのが、現時点での現実的な態度ではないかと考えています。
最後に私の個人的な話にはなりますが、次はLLMの構造それ自体に詳しくなりたいと思いました。最近「Software 3.0時代を楽しく生きる」という記事を読みました。Software 3.0ということは1.0と2.0もあるわけですが、これらを雑に要約すると、
- Software 1.0は従来のコーディングによるソフトウェア開発
- Software 2.0はニューラルネットワーク
- そしてSoftware 3.0はLLM
を指します。
私は知識が正直2.0で止まってしまっており、改めて3.0に追いつくために学び直す必要があると感じています。それは特に、例えばPlan Modeによってエージェントの行動の精度が上がるような話を、原理のレベルで理解したいと思ったからです。裏の構造を理解していると応用が効くとも言えることから、LLMにきちんとキャッチアップするのが次の目標になっています。
これからの時代において、LLMはOSですし、電力のようなインフラになっていることでしょう。Agentic Codingも将来、おそらく私たちが今や当たり前のように使うIDEやCI/CD、クラウドのような立ち位置になっていることでしょう。正直なところ、私はまだまだ手でコードを書くことに喜びを覚えていますが、「Agentic Engineering」の言うように、人力で確実に進めるところとそうでなく作業をスケールさせるところを上手に切り分けながら、Software 3.0時代を楽しんでいきたいと思います。
Sansan技術本部ではカジュアル面談を実施しています
とくにBill OneのAIエージェント活用を切り拓きたい方はぜひ！
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
