はじめに
この記事は SAP Advent Calendar 2025 の12月2日分の記事として執筆しています。
私は最近、個人開発でClaude Codeを使うようになりました。
特に10月からはほぼ毎日使うようになり、開発の進め方に少しずつ変化が出てきました。アドベントカレンダーをきっかけにこの3か月を振り返ってみようと思います。
コーディングエージェントについて、最初に考えていたこと
私の個人としての活動は、興味をもった技術や「やってみたいこと」を実装して検証するというスタイルです。ピンポイントの技術の確認が主なので、「どうやってやるか」をAIに聞くこともありましたが、実装までAIに任せるという考えはありませんでした。
使い始めたきっかけ
今年の9月にCAP、Fiori Elements、UI5用のMCPサーバーが登場しました。CAPやFiori ElementsはSAP独自の技術なので、AIと開発するにはSAP Build Codeでないとスムーズにできないのではないかと考えていたのですが、MCPサーバーをつなぐことでVS Codeでも開発できそうだ、となり始めてみることにしました。
エージェントとプラン
Claude CodeのProプラン（17 USD / 月）を使用しています。
最初に作ったものと学び
まずは「Claude Codeとの最適な付き合い方を見つける」ことを目標に始めました。そこでまず、「大きすぎて手に負えないもの」作ろうと考えました。普段の技術検証はピンポイントの技術を確認することが目的のため、自分で手を動かすことが重要です。一方で自分では手に負えないような大きなプロジェクトであれば、コーディングエージェントを使う甲斐があると考えたのです。
作ったものは「BTPのユーザ棚卸ツール」（サブアカウント、Cloud Foundry、IASに誰が登録されているかを管理し、棚卸実行で前回との差分を抽出する）です。期間にして1か月くらい取り組みましたが、（当然？）完成はしていません。
このときの学びは以下のようなものでした。
Claude Codeについて
- CLAUDE.mdに書いた指示が頻繁に無視される（例：todo.mdを更新すること）
- デバッグのためのログ出力が大量になる傾向がある（エージェントは「何が起きているか」をログで確認する必要があるため）
- 「コミットして、mainにマージして」など言えばやってくれるが、エージェントは「差分は何か」などを確認し始めるため時間がかかる
コーディングエージェントとの向き合い方について
- Claude Codeに書かせたコードをきちんと読むことが重要
- Claude Codeが計画・実装している間は、自分はコードを読んだり、次のステップを考えたりするとよい（作業の分担）
このときは「使いこなす」には至らず、あまりメリットも感じられず、しばらく距離を置くことになります…
現在どのように使っているか
CAP論理削除プラグインの開発
10月からCAP Node.jsの論理削除用プラグイン、cds-softdelete-pluginの開発を始めました。大まかな仕様をこちらで決めて実装してもらい、私が動かして不具合を見つけて直してもらっています。
プラグインは様々なパターン（ルートエンティティ vs Compositionのエンティティ、ドラフト有無、キーでのアクセス vs Navigation Propertyや$expandでのアクセス）に対応する必要があります。自分で実装しようとすると途方もない時間がかかりますが、コーディングエージェントを使うことでリクエストデータの解析からロジックの実装、テストまでを自動で行ってくれます。
さらに、裏側でCAP Java用のプラグインの開発も進めています。プラグインのスケルトンを自分で作ったうえで、CAP Node.jsの実装（Gitリポジトリのリンク）を渡して「Javaでも同じように実装して」と依頼したところ、爆速でJava版を作ってくれました。もちろん、すんなりとは動かなかったのでトライアル&エラーで直しています。Node.js版とJava版が並列で開発できるので、自分が二人以上に増えた感覚です。
エージェントルールの整備
開発をやりやすくするためにルール（CLAUDE.md、他）を都度見直し、エージェント自身にもフィードバックをもらいながら整備しています。
Codexにも手を出す
ChatGPTのPlusプランでCodexが使えるので、つい最近Codexも使い始めました。Claude Codeがメインですが、使用制限（5時間ごと）を超えたときのフォールバックという位置づけにしています。使ってみると全然違う！コーディングの品質を比較できるほどまだ使い込んでいませんが、始めに指示しておかないと勝手にどんどん進んでしまったり、必要最低限の応答しかしなかったりと、「性格」の違いを感じています。
コーディングエージェントとの3か月を振り返る
コーディングエージェントを使うときに意識していること
「あるタスクをAIにやらせるか、自分でやるか、決めるのは自分」ということを大切にしています。AIでやれば確かに速い。でも、その作業を自分でやりたければ時間がかかっても自分でやっていいと思っています。自分で手を動かすことで確認したり学べることがあります。
Co-Intelligence: Living and Working with AI （Ethan Mollick） という書籍で以下のような考え方が紹介されています。これはAIを使ううえでとても参考になりました。
AIのタスクと自分がやるタスクを区別する
- Just Me Tasks: 自分だけでやる
- Delegated Tasks: AIに任せ、自分がチェックする
- Automated Tasks: 完全にAIに任せる
- Centaurs and Cyborgs: ケンタウルス（Centaurs）は人がやるタスクとAIでやるタスクが線引きされている。AIに前作業をやってもらい、人は後作業をするなど。サイボーグ（Cyborgs）はAIと人が協調して行うタスク
また、コーディングエージェントの出力（思考のプロセスと結果）に目を通すようにしています。その考えが気に入らなければ、別の方法でやってもらいたいと指示するようにして、全てをエージェント任せにはしないようにしています。
コーディングエージェントを使ってよかったこと
論理削除プラグインの開発で実感しましたが、自分ひとりでやると膨大な時間がかかる作業をAIに任せられるので、まず「やってみよう」という気になります。これまでできなかったことが、AIの助けを借りてできるようになったのは非常に大きいです。
さらに、エージェントが自動で作業を進めてくれるので、これまで私の「検証の時間」は終わりが決まっていましたが、それを過ぎても、ご飯を食べたり歯を磨きながらでも細々と作業が続行できるのもよいです。
従来と変わったこと
テスト駆動開発になりました。自分で検証を行っていた時はテストを書くことはほとんどありませんでした。しかし、コーディングエージェントが実装したコードにすべて目を通すことは難しいため、先にテストを書いてもらい、テストが成功していることで正しく実装できているかを確認するようになりました。
開発スタイルについて改善したいこと
今回のプラグイン開発は「大まかな仕様を決めてエージェントに実装してもらう」というVibe Coding的なスタイルで始めたのですが、さまざまなエッジケースを考慮できていなかったことが後からわかりました。最初に机上で「これ以上は考えられない」というくらいに仕様を固めてから実装したほうがよかった（なんなら、そういう方法でもう一回やってみたい）と思っています。