【VibeCoding力】全ITエンジニアが今何よりも優先して学ぶべき知識

Devinが登場してからはや1年がたち、ClaudeCodeが駆け抜け1ヶ月。
現代のITエンジニアに最も必要なのは、対AIコミュニケーション能力であるかもしれない。
これからは末端エンジニアからAIを管理するリーダーに。技術100%から技術80%マネジメント20%の管理者へ。または、そこそこ出来る仕事爆速部下を1人追加で受け持つ事と同義でしょう。
それがこの単価と思えばClaudeCodeやDevinが今後開発業務に大幅に介入してくることはもう確実とも言えます。
そんなVibeCodingの時代に必要なVibeCoding力もとい、対AIコミュニケーション能力を養いましょう。

人がAIとタッグを組む事で、AI単独よりもより多くの事を成す事ができる。だが自律型AIエージェントがタスクをE2Eで処理する能力を得たことで、より高レベルのマルチタスクが可能になった。そして全てのエンジニアはプレイングマネージャーとなる。（意訳：最強エンジニア）

より忠実な翻訳（追記）
人とAIがペアになることでAI単独よりも多くの事を達成できる。自律型エージェントが、タスクをE2Eで処理する能力によって新たなレベルのマルチタスクを実現。全てのエンジニアがエンジニアリングマネージャーに転身する。

ちょっと翻訳文っぽさが強いので、意訳として私の翻訳を載せています。

はじめに

この記事はDevin公式 (https://devin.ai) によるCodingAgentガイドを元に執筆しています。
興味を持ったらぜひ下記リンクより一次情報も読んでみてください（当然英語ですが。。。）

Devin公式の発信ではありますが、この内容は以下の内容となっています。

• あらゆるコーディングエージェントで役立つヒント
• 実際にDevin開発陣が用いている考え方を元にしたアドバイス
• ITエンジニア向け（VibeCoding向け）のプロンプトアドバイス

あくまでVibeCoding向けのプロンプトアドバイスなので、AIの通常利用においては必ずしも適当とは限りません

本記事は大見出し（H2）単位で初級→中級→上級と推移し、最後は実践上での留意事項という構成になっています。最初の「対AIコミュ力の基本はプロンプトであり、上司力でもある」から順を追って読むことでVibeCoding力が飛躍的に向上し、投資効率を最大化することが出来ます。

本記事は、一次情報の適切な翻訳ではありません。
考え方をより自然な日本語に意訳し、実践すべき方法の前提となる考え方からまとめたより入門的な記事です。
すでに部下を持つ方や、結論どんなプロンプトを書けばいいの？と答えをストレートに希望する場合は一次情報を読んだほうが適切な可能性があります。

対AIコミュ力の基本はプロンプトであり、上司力でもある

対AIの指示能力、VibeCoding能力と聞くとAI時代の全く新しい能力と感じがちです。しかし、AI（人工知能）とは人工の知能であり、人を模したものです。そうですベースは人です。

ということは結局指示を出す人と指示を受けて行動する人であり、指示を受けて行動する人が指示を受けて行動するAIに変わるだけです。気づきましたね？それは上司と部下の関係なんです。

何をするかではなく、どのようにするかを伝える

「最強エンジニアくん、これやっといて」

文字にすると「最強エンジニア」のせいで成立しちゃってるけど、「ジュニア」に置き換えたらさあ大変。
いわゆるZ世代エンジニアで最悪のケースだと「何をしたらいいかわからなかったので何もしてないです」なんてこともありえそう…。当然そんな指示が良くないことだというのは明白です。

指示はより具体的に出しましょう。

ただし、真逆のケースもあります。あなたの理解度が高くない場合や、詳細に決まってないけどざっくり作ってほしい場合などです。そういった時はあえてざっくりと「何がしたい」を伝えて、方法の検討からエージェントにゆだねてしまいましょう。自由度をもたせる場合は大胆に、ガッツリしてほしいことが決まってる事はより具体的に。そういった指示の出し方を意識するといいかも知れません。部下と同様、裁量は適切に分配するのがいい上司です。

エージェントはジュニアレベルのコーディングパートナーである

エージェントの事はジュニアレベルのコーディングパートナーと考えるべきです。
意思決定が信頼出来ないことを念頭に、作業の道筋はマネージャーが示すのです。
シンプルなタスクは問題なくても、複雑なタスクの場合は最初から的確なアプローチを伝えてください。

特にゴールが明確な場合ほど細かい指示をすることで、意図した結果を引き出す事で出来るようになります。

必要な情報をきちんと伝える。丸投げクソ上司は対AIではもっとNG

どのファイルを確認するべきか。どのファイルから作業すべきかを明確に伝えます。
適切なディレクトリ構造の認識が無いジュニアに大まかな指示を出すと、意図していない階層にファイルを追加する事があります。エージェントも同じです。
また、全く関係ないファイルを読み込む事で、意図しない処理を作成することもあるでしょう。
新規機能開発であればスタート地点と、必要になるであろうモジュールのありかを伝える事で、モジュールを確認し、必要な物を適宜呼び出すはずです。

存在もわからないものは使う事はできませんからね！

Google Modelsのサポートを追加してください。
 - 最新のドキュメント: [リンク]
 - 実装場所: `model_groups/` ディレクトリ内に新しいファイルを作成
 - 参考実装: `openai_model.py` の構造を参考に
 - テスト: `tests/models/` に対応するテストファイルを作成

NG事項も正しく伝える

目的達成のためのアプローチはたくさんあります。が、現実問題選んでほしくない方法もあるでしょう。
その場合は事前にNGとして伝えるべきです。これは相手がエージェントであることは関係なく、人でも同じですね。

「せっかく頑張って作ったのにだめだと言われた…、そんな条件あるなら最初から言ってくれたらよかったのに」

上司の愚痴を言うジュニアくんの姿が目に浮かびますね。

ClaudeCodeの例ではありますが、XではIT企業の社長さんも言っています。
飛ぶ間際の派遣社員みたいなハードコーディングによるテストのパス。これはいただけない。先手を打って辞めさせます。

学習環境を整える

喜ばしい事にエージェントくんはエラーを見ても逃げ出しません。エラーを読み取り反復し、改善を試みます。そのため適切にエラーが出る環境こそがエージェントの最高な学習環境となります。
JavaScriptよりもTypeScript、Pythonよりも型付Pythonの使用を検討してください。静的型付けはエージェントの能力を上昇させます。

また、チェックとテストの実行方法を教え、必要な権限を付与しましょう。

実際にDevin開発陣も型付Pythonに移行しています

共通言語で正しく指示を出す

専門用語は使うななんて言葉も聞きますが、専門家同士の会話は専門用語をむしろ使うべきです。
数文字の単語で意味を適切に伝達できる、意思疎通に無駄がない（過剰でも過小でもなく、適切に言いたいことを伝えられる）専門用語を使わずに、概念の概要だけを伝えた場合。相手が運良く「この人の言いたいことはXXXXの事だな」と察してくれればコミュニケーションは成立しますが、それがなかった場合全く違う仕様が伝わる可能性があります。

自分の開発業務にエージェントを介入させる

当たり前の事を確認します。部下に与える仕事とはなんでしょうか。

部下を持った経験がない人にはちょっと考えづらい話かもしれませんが、それは【自分の持つタスク】です。
自分の持つタスク、自分に裁量が与えられているタスクだからこそ「誰かに任せる」という選択肢が取れるのです。

当たり前ですが、他の人のタスクを勝手に誰かにお願いしたら意味わからないですよね！

手を動かすのではなく、確認を主業務へ

自分の作業量限界を超えるだけタスクを受け取りましょう。「それ私やります！」とそうすると必然的に自分が作業していたのでは回らなくなります。そりゃそうです、限界を超えて受けているので。しかし仕事は受けた以上熟すしかありません。自分じゃない誰かを使う。そう、AIエージェントくんです。

Devinを採用している場合、多くの場合はSlackで @devin と付けるだけですから実際の部下よりも管理はとても簡単です。

寝る前、外出中、離席中…etc

あえて寝る前、外出前、離席前に仕事の事を考えましょう。経営者でもある私としてはプライベートの時間であったとしても提供するサービスは動いているので、完全に忘れるなんて事はありません。しかし1労働者からすると「プライベートの時間まで仕事？」となると思います。その通りなので、寝る前は趣味開発だけにしましょう。

としょうもない話は本題ではないので、進めます。しかし、もう一度当たり前の事を言います。

「離席中や退勤後、外出中は開発タスクは止まります」

PCの前に自分がいないのだから作業は当然止まっているはずです。
気づきましたか…？その時間、作業を進める方法があるじゃないですか。それがエージェントです。

複雑な開発タスクを依頼しなくてもいいんです。
「このエラーについて調査して」
「この処理にこんな事したらエラーになるかテストして」
「新しいライブラリを使いたいのでドキュメントの確認と、サンプルコードの作成をしてほしい」
外出中にだってエラーの連絡があるかもしれないし、寝る前に今日書いたコードに不具合があるかもと気づくかもしれない。そんな時にささっと指示を出します。人間の部下だとパワハラ最低上司に一瞬で成り下がりますが、AIエージェントならそんな事はありません。

これはプロンプト術というよりは、AIエージェントを活用した生産性向上の方法です。
たった数分仕事脳に切り替えるだけで大きなメリットを得られるので、意識して活用しましょう。

手間な作業ほどエージェントへ

これは私だけではないと思うのですが、ぶっちゃけ「ドキュメントの更新めんどくさい・・・」って思いませんか？
関数の定義時にはその説明を書くみたいなコーディングルールを見たことがある人は多いと思います。

これはかなり誇張というか無駄を突き詰めた悪い例ですか、下記みたいなやつです。

/**********************************************
Name: HogePiyo
Auther: StrongEng
Args
hoge: hogehogehoge
piyo: piyopiyopiyo
Return: none (error only)
**********************************************/
func HogePiyo (hoge string, piyo int) error {
  ...
}

ただし、正しくメンテナンスされ内容もその関数をひと目見て(内部の処理を理解しなくても)使えるレベルのテキストが用意されているのであれば、十分有意義なルールです。

ただ、ただ！！！！更新忘れる人がいるし、なんだかんだ書くのはめんどくさい！

そうなんですめんどくさいんです。でも安心してください。こういう作業こそエージェントくんが得意です。

Devinの開発チームはプログラムを人が修正し、関連するドキュメントの修正をエージェントに任せるという運用をしているようです。

考えるな、実装して明確な数字で判断を

プログラミングには一定の時間がかかります。それなりな機能開発や既存コードのリファクタリングなんて考えた場合事前に一定の検討をしてからでなければ、プログラミングにかける工数を後々無駄にする可能性もあります。
そのための上流工程ですからね。

しかしAIエージェントによってあり方が変わります。

エージェントに両方実装させましょう。その上で触ってみて意思決定をするのです。意思決定の精度もあがり、そのまま雛形やサンプルコードとして活用もできます。
AIエージェントは完璧のシニアエンジニアではないので、目的のコードをバチッと書くことは難しいです。しかし、比較検討段階の場合、その開発速度を上司として活用し、プロダクトを加速させましょう。

Devin開発チームはLexicalJSとSlateJSのどちらを採用するか決める際、実際にAIエージェントに開発させて検討したようです。（その結果SlateJSを採用しました）

ジュニアだって成長していくし、成長してほしい

これまで紹介した運用は通常1時間もかからない物ばかりです。（数分ｘ物量による結果数時間みたいなのは除く）
しかし、それではAIエージェントにあなたが付きっきりとなってしまい健全とは言えません。
そのためにはAIエージェントにも成長してもらい、数時間相当の作業を任せていける環境を上司であるあなたも、部下であるAIエージェントも作る必要があります。

エンジニアからマネージャーへの転身

これまでもAIエージェントを部下として見る事を伝えてきましたが、AIエージェントに与えるタスクが2時間クラスになってくると本格的にその形が見えてきます。
細かいタスクをAIエージェントに与えている段階では、AIエージェントの実行を眺めてコーヒーを飲んでいると完了するといった事もあると思います。それでは休憩時間は確保できても、自分で仕事しているのとかわりありません。

プロトタイプエンジニアとして

大規模タスクの場合、AIエージェントの強みを活かす方法は初期ドラフトを作成させる事です。いわゆるたたき台やプロトタイプと呼ばれるブラッシュアップを前提として初度の物をAIエージェントに作成させます。
このタスクは品質よりもスピードに重点が置かれるため、AIエージェントの活用方法として適しています。

あくまで成長したとしてもジュニアエンジニアです。AIエージェントは手放しで大規模タスクを任せられるほど優れていません。
AIエージェントの活用目標は高いROI（投資収益率）であり、手放しで何でも実現してくれるものではありません。
時間削減による効率化であり、品質の担保は上司であるあなたが担います。

PRD作成に参画させる

難易度の高いタスクや定義が曖昧なタスクについては、開発ではなくPRDの段階から参画させるのも効果的なアプローチです。

エージェントに質問形式で問いかけ、少しずつあなたの頭を整理し、要件として落とし込むのもいいでしょう。
DevinやClaudeCodeなどのエージェントにはファイルの読み取りと調査に特化した専用のモードが提供されているものもあります。
新規機能としてやりたいことと、既存コードの兼ね合いなども考慮して提案をだしてくれる所は実際の開発タスクよりも上司を強力にサポートするかも知れません。

適切なタスクの分割

大きなタスクは基本的に小さなタスクの集合体です。全ての修正が完了してから確認するよりも、適切なポイントで確認を挟んだほうが戻りが少なくなるのは自明です。

具体的にはレイヤーをまたぐ開発（フロントエンド、バックエンド、DB等）や、複数モジュールの新規開発を伴う大きな機能追加などです。それらは「ここまで出来たら共有して」と指示し、成果を承認することで戻り作業を減らしより効率的に大きなタスクを任せられるようになります。

確認が大事って言ったよね

「お前修正したあと確認してねぇだろ！！！（コンパイルが通らないコードを見ながら）」
なんて経験ありませんか？　私　は　た　く　さ　ん　あ　り　ま　す　。
失礼しました、つい過去の苦い思い出が感情の濁流となり無意識にタイピングしていたようです。

そんな時、部下にはどのように伝えるか、めちゃくちゃ迷うわけですよ。こういう確認が出来ない人のほとんどは何百回と言っても繰り返すので…。（だからこそCI/CDみたいな方法で自動化し、提出時に自分で気づく環境が用意される時代担ったと思ってます。）

しかし、AIにはそんな事気にする必要はありません。定期的に失念することはあっても1度いえばだいたい聞いてくれます。

ただし「この機能動いてないよ」みたいな指摘はNGです。きちんと掘り下げて指摘しましょう。

また、AIエージェントは良くも悪くも指示通りに行動するので、作業プロセスとして確認工程を明確にする事も重要です。TDDの考えを教え込み、テストを書く、エラーを出す（未実装なので当然）、実装する、テストが通る事を確認するといったフローを明確化し、検証結果として報告の雛形まで定義しておくとなおよしでしょう。

エージェントの能力を正しく評価し、教育する

組織には色があり、チームには独自のルールがあります。AIエージェントにはきちんとそのルールを教えましょう。
あなたが理解していても、AIエージェントがそれを理解しているとは限りません。
なんといってもジュニアですからね、みっちり色を染め上げましょう。

各社AIエージェントにはなんらかの継続的なメモリ保存または動作規範を設定・定義する仕組みがあります。ClaudeCodeならCLAUDE.mdといった形で定義し、AIエージェントに正しい行動を教えましょう。

ジュニアでも得意領域ならミドル、シニアクラスの働きも

例えば大学での専攻がIT外の分野だった場合。会社でその事に対して一番詳しい人は新人エンジニアである事も珍しくありません。そのようにジュニアだとしても得意領域ならミドル・シニア並、またはそれ以上の活躍が期待できる可能性があります。

業界のスピードスターことAIエージェント

AIエージェントは人間よりも遥かに早く着信イベントに応答できます。

SSランクの単純作業適正

開発をしていると、反復的ルーチンワークによく遭遇します。これらはAIエージェントによる自動化に適正があります。

これらを効率的に行うために再利用可能なプロンプトテンプレートを作成しましょう。

Devinを利用する会社には、新機能が開発されるとユニットテスト作成専用のエージェント3つを自動的にトリガーする仕組みを運用しているようです。

記憶力ギフテッド

人間の記憶はインデックスに合致すると想像を絶する速さを発揮しますが、その容量は限界あります。プロダクトの規模が大きくなると、プログラムのすべてを保持することは難しいでしょう。

しかし、AIエージェントであれば事前にリポジトリを読み込みより正確な見解を提供することが可能です。
新規のPR毎にエージェントがその内容を精査する事は品質管理において非常に効果的と言えます。

神速のファーストタッチ

特定のイベントに応じて自動的にトリガーする事で、AIエージェントに最速でアラートをフックさせることが可能です。

それにより、人間が確認する段階ではある程度原因が調査された状態にできます。これらはサードパーティ製のMCPを活用し、エラーを解析させる事でより精度が向上します。

AIエージェントのデバッグ能力はあまり高くはないので、本番環境のエラートリアージには適しません。
最速で検出し、問題を検証・一次調査程度に留める事が現状では適切な運用です。

作業だけじゃなく、成長も爆速

AIエージェントの強みは、成長面でも爆速なこと。

一度言ったことは原則その通り動作します。コンテキスト量もありすべてを記憶することはないし、定期的に忘却しますが、その都度コンパクトにまとめたCLAUDE.md等を参照する事により業務の基本知識は欠落することなく維持されます。
AIエージェントは予測しない動作をすることもありますが、それらは教育不足の証拠です。正しく教育しましょう。

教育環境を整える

チームで開発をする場合、まずは環境を統一しましょう。
言語のバージョン、パッケージの依存関係、lint等の自動化チェック等。

人とAIエージェントすべてにフレンドリーな環境が重要です。

エージェントが使うブラウザを事前認証済のログインで設定することで、手動認証の手間がなくなり、テストが効率化します。

道具はきちんとした物を与える

適切なMCPを設定する事でAIエージェントはより能力を発揮することが可能ですが、それと同時にエージェント向けのシンプルなCLIの設定は見落としがちです。

Devinを利用する会社には、テストスイート内の最初の失敗にフォーカスし、表示するCLIツールを作成し、大きな効果を発揮した所があるようです。
このCLIツールは詳細なエラー情報とともにAIエージェントにそのテストにのみ集中するよう指示をし、成功率・完了率の向上に貢献しました。

時には上司権限で強制力を発揮する

AIエージェントにタスクを依頼していると、何かしらのミスを犯すことがあります。その時は .rules や CLAUDE.md 等に新たに記載し、矯正しましょう。AIエージェントの挙動を上司特権により強制することで成長を促します。

また、事前に考えられるケースは最初から定義しておくことでAIエージェントの効率が大きく上昇します。

教育するにしても当然限界はあるわけで

2025年6月現在、AIエージェントの能力は比較的低めと言わざるを得ません。しかしそれを補ってあまりあるほどの教育環境があります。とはいえコンテキストサイズの都合上特大規模のプロジェクトではその実力を発揮するのは難しい事も想像できます。

基礎能力的な制限

広く浅く万能な珍しいタイプなジュニアですが、そんなAIエージェントにも明確に苦手とするものがあります。

ジュニアが勘違いしがちな、テスト。実はそれ高次元のタスク

よくテストテストしかやらせてもらえない、Excelにずっと書き込んでるだけ・・・。といったITエンジニアのキャリアパスに不安を覚えるSESワーカーが日本のIT環境ではちょこちょこ話題になりますが、本来テストというのは高次元なタスクであり、誰でもできる事ではありません。
完全に定義されたテスト設計を元に「テストを行い、チェックをするだけ」というタスクに落とし込まれているからこそ、未経験のジュニアに任せられるのです。

AIエージェントのバグレポートも一見綺麗にまとまっていてよく見えるかもしれません。しかし、多くのバグはログやデータへのアクセスだけでなく、AIエージェントでは対応出来ないレベルのデバッグ作業が必要です。
AIエージェントをデバッグ支援に活用する場合は、すべて任せるのではなく使い方に注意しましょう。

エージェントくんは視力よわめ

VibeCodingをしてみるとすぐに分かることですが、デザインと一致する物を開発する能力がかなり低いです。
実際に目でみて判断するわけではなく、コード的に「こう表示されるだろう」ということを前提にしているといえばわかりやすいかも知れません。

身に覚えがありませんか？「出来ました！」といって一切動作確認していない物を渡してくる新人くん。
原因を特定し「ここをこうすれば治る」と頭の中で決めつけているからこそ、実際の結果を確認せずにコード上を書き換えただけで確認を行わない。駄目な事は当然ですが、そういう人間の心理というか行動は理解できるし、これはなかなか治りません。フロントエンドはAIエージェントにとってそういった所があると覚えておく必要があります。

知識力はあるが、古い事が多い

特定ライブラリを利用させる場合、まず最初に最新ドキュメントを明示してください。これはもうCの #include <stdio.h> をおまじないと言うように、理解してもしなくてもいいです。必ず徹底してください。

LLMの技術的な問題として、学習データに依存する所があります。それは時間が経てば立つほど古い知識としてギャップになります。そのため、絶対に最新情報を与えてそれに則った対応をさせてください。

タスクの見極めと巻取り

何度も言っていますが、AIエージェントはジュニアレベルのエンジニアです。当然完璧ではありません。
AIエージェントをどう活用するかを学ぶ事もこれからの時代の全エンジニアマネージャー時代には必要な事でしょう。

現実問題として、トークン消費という体力みたいな物があり、API使用料という人件費も掛かります。
無尽蔵にリトライさせて完成するまでAIエージェントに任せるというのは非現実的な部分をあることは抑えておくべきです。

「まずはありがとう」と伝える勇気

ドキッとする人もいるでしょう。ただし相手は良くも悪くもAIです。曖昧な言葉で濁し、ぐだぐだするのは得策ではありません。サクッと伝えてしまうのも必要な事です。

私もVibeCodingを始めたばかりの時はやらかしていたのですが、AIエージェントに思った通りの作業がしてもらえなかった時。必死に軌道修正をして成功にこじつけようとしていました。

結果として完了する事もあれば延々とグダって翌日別セッションで…という事もありました。そして別セッションですこし指示の仕方がことなっただけでスムーズに完了したことも…。

なんかぐだっているなと感じたら作業を巻き取る事や、セッションを中断する事も念頭においておきましょう。
人はセッションを切り替えても、以前のセッションで得た情報を引き継げます。その情報を元により適切な指示を出すことでクリーンな状態のAIエージェントに的確な指示をだす事でAIエージェントもタスクを完了させる事ができるかもしれません。

上司にも練習期間を

AIエージェントの能力を引き出す上司も最初から完璧なわけはありません。なんならAIエージェントよりも多くの時間をつかい練習する必要があるでしょう。

最初は多角的にアプローチをおすすめします。様々なプロンプトやアイデアを試し、AIエージェントの成果をみて少しずつ何が得意なのか、どの程度できるのかを自身の感覚で覚えることが重要です。
AIエージェントは同じ能力でも、指示者の熟練度に応じて大きくその姿を変えます。まずは自分の指示でどの程度の成果を出すのか、どういう指示に変えると成果があがるのかを理解しましょう。

簡単にクビにできます。そう、AIエージェントならね

AIエージェントはセッションの概念により、人間よりも遥かに「やりなおし」による成功確率が高いです。

タスクの結果にフィードバックを与えてみて、軌道修正やフィードバックへの対応に苦労する場合は新しいAIエージェントにすべての指示をあたえてやり直す事で多くの場合は結果的に早く成功にたどり着けます。

セキュリティ管理・リスク管理

先日こんなポストがIT界隈でぷちバズってました。

UPDATE分だったりするタイポや、ポストの内容及びリプライや引用の内容の賛否はともかく。ITエンジニアだって人です。やらかすんですよ！

なおさらAIエージェントがやらかさないなんて理由ないわけです。

ClaudeCodeが出た当初はやたらと全削除された！みたいなポストも見かけましたしね。

専用のアカウントを与えよう

ジュニアエンジニアに本番環境のDBへアクセス権がほしい（調査のためにデータが確認したい）と言われた時。どうしますか？
普通、ROの権限を作成し渡すと思います。開発環境のつもりでTRUNCATEしたら本番だった！なんていうミスは起こり得ないようにするのが対策ですからね。人は間違うものなんです。

ではAIエージェントにはどうするか。同様です基本的にROの権限を渡しましょう。またテストの自動化にはメールアドレスが必要なケースも多いです。使い捨てのメールアドレスなども活用しましょう。
AWSの権限を渡す場合はかならず専用のIAMを定義し、間違っても勝手に変更されないよう。間違えが起きない環境を作る事が重要です。

開発環境を与えよう

Dev/Stg環境を用意するのが理想的です。個人開発であればローカル実行環境だけで十分ですが、チーム開発の場合はみんなが共有できる環境を使用すべきです。また、本番環境へのアクセス許可は限定的にしましょう。何度もいいますが、壊れて殻では遅いです。開発環境で正しく動作した変更を責任を持ってAIエージェントの上司であるあなたが反映しましょう。

基本的には読み取り専用権限を与えよう

一番大切なことなので、もう一度いいます。
AWSのIAM、DBのユーザ、外部サービスのAPIキー…etc。

可能な限り読み取り専用の物を用意してください。

なんなら今日はこれだけ覚えて帰ってもらえれば大丈夫です。
「AIエージェントには読み取り専用の権限を！」マジで大事です。 rm -f された！とかネタにできるプロダクトであればいいですが、クライアントのファイルを…なんて話になったらもう真っ白ですからね。

まとめ

ClaudeCodeが登場してはや1ヶ月。この記事の着想から3週間。

・・・え？マジ？三週間？サンシュウカン！？

最初はさくっと日本語でまとめるつもりだったんですよ。でもさ、最近のウェブ翻訳って優秀じゃないですか？単なる翻訳だと1mmも意味がないな！？って思ったんですよね。

というわけで、「VibeCodingのおともであるAIエージェント」という事で、Vibesで記事を書いたつもりです。いかがでしたでしょうか。多少なり面白かったと思えた＆役に立つと思えた人がいたら幸いです。
普段こういう内容は真面目に書くけど文章はふざけるみたいな言葉と意味を大きく乖離させるみたいな文章は書かないのでめちゃくちゃ時間がかかりました。二度とやりたくないです。

想像できない大きな未来

ITエンジニアはこれまでも爆速で進化するフレームワークや次々に現れる新しい技術に翻弄されてきました。
これからはAIエージェントの進化にも翻弄されることでしょう。
ただしそれは、これまでのリスキリングを要求される変化ではなく、これまでの学びを捨てて他のレイヤーに挑戦するというサンクコストやフットワークの軽さ、プライドといった側面だと思います。かといってこれまで身に着けた開発能力が無になるわけではなく、レビューや評価といった側面が強くなるまさにマネージャー的立場です。

AIに出来ること、人がしたほうがいいこと。まだまだわかりませんが、そこを適切に見分けて学んでいきたいですね！

あとがき

私自身DevinとClaudeCode日常的に使い、Copilotにサジェストしてもらいながら日夜開発業務を行っております。
実際DevinやClaudeCodeがどの程度の品質のコードを生成できるのかは未だに図れない所があります。
それは、AIエージェントとしての本当の実力がアウトプットから見える程度なのか、私の指示や運用が悪くジュニアエンジニア止まりなのかわからないからです。

DevinのOSS版としても有名な OpenHandsもコミット数2位は openhands-agentとAIがAIを開発する時代です。その実力があると考えると、私がDevinやClaudeCodeを十二分に使いこなせておらず、過小評価してると考えるべきだと思っています。

また実際の所、あらゆるCodingAgentで汎用的に使える知識ではありつつも、DevinとClaudeCodeで比較しても大きく異なる所があります。（コンテキストとして事前に定義する方法や、その内容等）

今度はそれらを踏まえ、ClaudeCodeをジュニアからミドルに成長させるコンテキスト定義、プロンプト術みたいなより実践的な方法をまとめる予定です。