AI

2月からClaude Codeを使い始めた。ターミナルから使えるAIコーディングエージェントで、コードの読み書きから実行まで自律的にこなしてくれるツールだ。前回のAgentic Codingの記事でも触れたように、仕様から実装まで任せられるようになってきている。使い始めて数週間、うまくいくパターンが見えてきた。一言でいうなら、Claudeをチームメンバーとして動かす意識を持つかどうかで、結果が大きく変わる。 バックログとドキュメントで共通認識を作る 思いついたことはとにかく起票する。実装中に別対応が必要になったものも、その場でチケットに起こしておく。これを徹底したことで、作業中に「あれもこれも」と頭が散らからなくなった。積み上がったチケットは重要度と前後関係で並べ直し、優先順位を明確にしながら進める。バックログの整理は、チームの足並みをそろえる作業とまったく同じだ。 CLAUDE.md に意図を、SPEC.md に仕様を書くようにした。これで人間もClaudeも迷う場面が明確に減った。「このプロジェクトでは何を大事にするか」「この機能の仕様はどうなっているか」が参照できる状態にあると、指示を出すたびに説明し直す必要がなくなる。新しいメンバーにプロジェクトの背景を渡すドキュメントを書く、という感覚に近い。 アプリの処理フローが複雑になってきたタイミングで状態遷移図を作ったのも同様の効果があった。どこが複雑なのかが一目でわかる。コードを直す前に「そもそもこの状態遷移をシンプルにできないか」という観点で考えられるようになった。 テスト・計測で品質の基準を揃える TDDを取り入れると、Claudeが実装中に不具合を自発的に見つけて対応してくれることが増えた。「このテストパターンだとこのケースが漏れていないか」と指摘もしやすくなる。共通のテスト基盤があることで、品質の議論が「感覚」から「事実」になる。 E2Eテストも同じ文脈で導入した。UIの挙動を変えたときの品質が担保できるし、エラーが出たときに「E2Eの何番がこけている、エラーメッセージはこれ」と伝えるだけで話が早い。再現手順を言葉で説明する手間が省けて、対話のテンポが上がった。 計測を徹底したことも大きかった。処理速度やレスポンスタイムを実測するようにしたことで、人間は「体感遅い」、Claudeは「理論上はやい」と違う基準で話していたのが、実測値で一本につながった。共通の基準があると、議論の質もコードの質も変わる。 振り返りとコミュニケーションで精度を上げる RETROSPECTIVE.md を作り、作業ごとに「良かったこと・伸びしろ・ネクストアクション」をまとめるようにした。振り返り用のスキルをClaude Codeに登録しておき、まずClaudeに下書きを書かせる。それを読んでフィードバックを出す、という流れだ。ネクストアクションのうちドキュメントで対応できるものはその場で更新、実装が必要なものはissueを立てて次に回す。振り返りを回すほどドキュメントが育ち、Claudeへの指示精度も上がっていく。 着手前に「作業手順や仕様で質問はある？」と聞くようにしたのも効果があった。実際に仕様の確認が返ってきて、自分の考慮が足りていない部分だったこともある。「着手したら実は仕様が曖昧だった」を事前につぶせる。チームでいえば、タスクに取り掛かる前のちょっとした確認と同じだ。 言葉の選び方も変わった。「根治」「徹底的」「念入りに」という言葉を使うと、ソースコードを探索するときの精度が上がった気がする。「根治」は特に効いた。不具合に遭遇したとき、その場しのぎで終わらせずに原因を取り除きにいってくれた。強い命令口調より、方針を示す言葉のほうが意図が伝わりやすい。 チームでのコードレビューと同様に、実装が一段落したら必ずレビューを挟む。Claude Code の /review コマンドはいい感じに不具合を拾ってくれる。/simplify は冗長なコードを整理してくれるが、コードを壊す可能性もあるので慎重に使っている。 雑感 振り返ってみると、ツールの方向性を示し続けるプロダクトオーナーとしての比重が大きかったと思う。一通り実装してPRを作ったら振り返り、次に何をしたらよくなるかを考える。そして次の振り返りで試した結果を確認する。Claudeが爆速で走れる状態を作ることがとにかく楽しかった。 この感覚は、スクラムマスターとしての経験が活きていると感じた。障害を取り除いてチームが動きやすい状態を作る、という役割がそのまま当てはまる。Claude Codeとうまくやるコツは、開発チームをうまく動かすコツと根っこが同じかもしれない。 今回はRust + Tauriという自分にとって未知の領域で試したが、知らない言語でも計測手段とゴールが揃っていれば任せられることがわかったのは収穫だった。ただし未検証の部分も残っているので、引き続き使いながら確かめていくつもりだ。 結局のところ、AIとうまくやるコツは、チームとうまくやるコツと同じだった。共通認識を作り、基準を揃え、振り返りで改善する。その繰り返しだと思う。

Vibe Codingを試してみた 「いい感じにして」とプロンプトを投げたら、数分で動くものが返ってくる。最近話題のVibe Coding、そしてその先にあるAgentic Codingを試している。 Vibe Codingはプロトタイピングにちょうどいい。簡単なプロンプトでサクッと作れるし、動かしてみて初めて機能の過不足に気づくこともある。思いついたアイデアを雑にでも形にできて、フィードバックループが短い。この速さが最大の魅力だと思う。 実際、ちょっとしたツールやスクリプトなら、プロンプトを1つ2つ投げるだけで動くものができあがる。「とりあえず触れるもの」が数分で手に入る体験は強力だった。 ただし、勢いで作っている分、どんな機能があるかは触ってみないとわからない。条件分岐の詳細を知ろうとすればコードを読むしかなく、そうなると作り直したほうが早い。裏側はAIがよしなに決めた構成になっているから、後から手を入れると、数年前に書かれたコードを読み解くような労力が生まれる。ここがVibe Codingの限界だった。 規模が大きくなると何が起きるか では、もっと大きなものを作ろうとするとどうなるか。プロンプトだけで指定しても、収拾がつかなくなる。長いプロンプトは解釈がブレやすいし、コンテクストウィンドウから溢れやすい。 そこで必要なのがドキュメントだ。仕様書や実装計画の叩き台を作り、フィードバックを出し、ブラッシュアップを繰り返す。 仕様書といっても「このような機能がほしい」を SPEC.md というファイルに列挙し、Claudeに根掘り葉掘り聞いてもらい、ブラッシュアップする。その SPEC.md に書かれた機能をいくつかの段階に分けて、最初にこれを作り、次にあれを作り、とわける。ドキュメントとしてはかなりライトだと思う。 ノリと勢いで投げるのがVibe Codingだとすれば、人間とAIがそれぞれ担当を決めてAIも自律して動けるのがAgentic Codingといったところだろうか。 Agentic Coding の始め方・ツール選び 自分が試しているのはClaude CodeとCodex CLI。どちらもターミナルから使うCLIツールで、エディタを選ばないのが気に入っている。 両方とも個人向けの一番安い有料プランでコーディングエージェントが利用できるので採用した。 今のところ、仕様作成から実装はClaude Code、細かい修正やコードレビューはCodex CLIの棲み分けになっている。 ここで重要なのがAIにプロジェクトの文脈を渡す仕組みだ。Claude Codeなら CLAUDE.md にプロジェクトのルールや構成を書いておくと、AIがそれを踏まえて動いてくれる。Codex CLIにも同様の仕組みがある。「このプロジェクトではこういう方針で」という申し送りをファイルに残しておく感覚だ。 小さく始めるなら、まずは既存プロジェクトのちょっとしたリファクタや、テストコードの生成あたりがおすすめ。いきなり大きな機能をまるっと任せると、期待と出力のギャップに戸惑う。小さいタスクで「AIとのやり取りの勘所」を掴んでから、徐々にスコープを広げていくのが無難だろう。勝手がわかれば、ベストプラクティスが参考にできるようになる、と期待している。 人間の役割はどう変わるか Agentic Codingを続けていると、自分の役割が明らかに変わってきた。 コードを書く時間が減り、代わりに増えたのは「何を作るか決める」「どう作るか設計する」「出てきたものをレビューする」時間。書く人から、考えて確かめる人へのシフトが起きている。 「何を作るか」「なぜ作るか」は、今のところ人間にしかできない。ドメイン知識や価値の判断はAIに丸投げできない領域で、ここの解像度が低いとAIの出力もぼんやりする。逆に、ここがしっかりしていればAIはかなり良い仕事をしてくれる。 品質の最終責任も人間にある。コードが正しいか、セキュリティに問題はないか、パフォーマンスは大丈夫か。こうした判断はレビューする側の力量次第だ。今回はあえて実装はAIに任せることにした。なので自分が担当するのは最初の実装のプランと成果物を使ってのフィードバックが主、それとAIに必要な情報が伝えられるようドキュメントの整備。 面白いのは、AIに指示を出すには要件を言語化しなければならないこと。「なんとなくこうしたい」では伝わらないから、自然と思考が整理される。副次的な効果だけれど、設計力を鍛える訓練にもなっている。 まとめ Agentic Codingは「使える」段階に入っている。ただし、魔法の杖ではない。雑に投げれば雑な結果が返ってくるし、的確に指示すればかなり良いものが出てくる。道具としての性質は、従来の開発ツールと変わらない。 自分としては、今後もAgentic Codingの比重を増やしていくつもりだ。何が作りたいのか考えることにもっと時間を使えるようになるのは、ありがたい方向性だと思っている。 興味がある人は、まず手元の小さなタスクで試してみてほしい。使ってみて初めてわかることが多いから。

ゆるっとSsalesforce co-meeting社のエンジニアが運営するオンライン勉強会、隔週でお昼の時間帯に30分枠で開催されている。 今回はその第50回目。 ゆるっとSalesforceトーク #50 Coral Cloud Resorts を触ってみた - connpass 開発者向けAgentforceはじめの一歩？ Coral Cloud Resorts を触ってみた これから触る人向けに軽くやっていきたい 去年の12月に公開されたデベロッパー向けのブログで存在を知った Salesforce、Data Cloud、Amazon S3を組み合わせたサンプルアプリケーション プロンプトのサンプルも提供されている。また、ページに Agent が組み込まれているので、すぐに試せる 実際に試してわかったこと 基本は Trailhead に従って環境を構築すれば良い 手順に関してはかなりざっくりと書いてある GitHub のリポジトリを参照しながら構築作業を行うが、高頻度で更新されているため、リポジトリ内の導入手順書通りにやってもエラーが出ることがある 別に公開されている記事を参考にすると、素早く環境構築がしやすい Agentforce と Data Cloud を使用した Salesforce組織が必要。Trailhead を利用すると、必要な機能が使えるSalesforce組織が無料で作成可能、5日間の利用期限あり インストールするパッケージのバージョンがドキュメントによって異なる。GitHubのドキュメントを確認した方が良い モデルは手作業で作る必要あり Amazon S3 から取り込む方法がどうも記述に間違いがあるらしい Agentforce の Workshop に沿ってやると理解が捗る ノート 無料で試せる環境が構築できるのはとても良さそう 他の会も含めて賑やか和やかに進行しているのがまたよき