【勉強会】AIにコードを書かせて満足してない？Claude Code時代の開発組織について話しました

最近のAI、もう「質問に答えてくれる相手」ではなくなってきました。ファイルを読んで、コードを書いて、テストを走らせて、失敗したらエラーを読んで直す。Claude CodeのようなAIエージェントを触っていると、開発の進め方そのものが変わっていく感覚があります。一方で、実務に入れようとすると考えることもたくさんあります。AIにどこまで任せるのか。どうやってレビューするのか。勝手に危ないコマンドを実行しないようにするにはどうするのか。AIが書いたコードを、人間が毎回目視で確認し続けるのは本当に正しいのか。そんな問いを持ち寄って、社内でAI活用に関するライトニングトークを開催しました。

当日は、Claude Code、Claude.md、Skills、静的解析、CI、サンドボックス、障害分析、ナレッジ共有など、かなり実務寄りの話が中心。「AIすごいよね」で終わらず、どう開発フローに組み込むか、どう安全に使うか、そしてエンジニアの役割はどう変わるのかまで、現場のメンバーで話しました。

この記事では、その中でもエンジニアの方にタイムリーなトピックを中心に紹介します。

AIを“使ってみた”のその先へ

今回のライトニングトークのテーマを一言でいうと、「答えるAI」から「動くAI」へ です。

これまで業務でAIを使うといえば、ChatGPTなどに質問して、文章で回答をもらう使い方が中心でした。たとえば、

• メール文面を整えてもらう
• 議事録を要約してもらう
• アイデアを出してもらう
• 調査や設計の壁打ちをする

といった使い方です。もちろん、これだけでも十分便利です。
ただ、Claude CodeのようなAIエージェントは、その一歩先にいます。

ローカルPC上のファイルを読み、コードを書き換え、コマンドを実行し、テスト結果を見て、必要なら修正する。つまり、AIが「答える」だけでなく、実際に手を動かしてタスクを進める存在になりつつあります。そうなると、開発現場で考えるべきことも変わってきます。単に「AIに実装させる」だけではなく、AIが動きやすい開発フローをどう作るか、AIが間違えたときに、どう検知するか、危ない操作をどう防ぐか。
そして、人間のエンジニアはどこに時間を使うべきなのか。

今回のイベントは、まさにそのあたりを現場のメンバーで持ち寄って共有する場になりました。

非エンジニア向けのパートもあり、非常に大盛況でした！

1.Claude.mdとSkillsで、開発フローをAIに“つなげて”もらう

最初にご紹介するのは、Claude.mdとSkillsを組み合わせて、開発フローそのものをAI向けに設計する話です。

「Claude.mdだけだと、まだちょっと出力に不満が残る。
でもSkillsと組み合わせると、Claude Codeの動き方がかなり変わります」

新卒入社2年目のS.Sさん。フレッシュながらに期待のホープです。

そんな話から始まった発表では、要件整理からレビュー、テスト、コミットまでを一連の流れとしてAIに任せる取り組みが紹介されました。

Claude.mdは、AIに対するルールブックのようなものです。
プロジェクトの方針、コーディング規約、ドメイン知識、注意点などを書いておくことで、Claude Codeに開発時の文脈を渡せます。

一方、Skillsは特定の作業を再利用可能な形にしたものです。
スラッシュコマンドのように呼び出して、要件整理、レビュー、テストなどを定型化できます。

特に反響があったのが、要件を深掘りするSkillで、たとえば「お気に入り機能を追加したい」と入力すると、AIが仕様確認の質問をどんどん出してくれます。ユーザーはその質問に答えていくことで、実装前に仕様を明確にできます。その後、別のSkillが依存関係や実装順序を整理し、さらに実装、レビュー、テストへとつなげていきます。

レビューでは、以下のような観点をAIに並列で見てもらいます。

• セキュリティ
• パフォーマンス
• N+1問題
• コーディング規約
• 循環的複雑度
• ドメイン知識との整合性
• 境界値
• 異常系
• ビジネスルール
• テストコードの妥当性

CriticalやMajorの指摘が出る限り、AIが修正と再レビューを繰り返す構成です。

ここで面白いのは、AIに「いい感じにレビューして」とお願いしているだけではないことです。
どの順番で、どの観点で、どこまで自律的に動くのか。そのワークフロー自体をエンジニアが設計しています。AIを使うというより、AIが動きやすい開発レーンを作っている感覚に近い発表でした。

2.AIが「完走」できる開発環境を作る

スペシャリストのT.Hさん。スペシャリストらしい非常に機知に富んだ内容でした

別の発表では、AIが「完走」できる開発環境について話がありました。ここでいう完走とは、AIがコードを書くだけではありません。

• 実装する
• テストを実行する
• 静的解析を実行する
• エラーを読む
• 自分で修正する
• 再度テストする
• コミット可能な状態まで持っていく

この一連の流れを、AIが自律的に進められる状態を指しています。今は多くのチームで、AIにコードを書かせるところまではできるようになってきています。ただ、その後に人間が差分を見て、テストして、エラーを読んで、修正して……という流れになりがちです。

もちろん人間の確認は必要です。しかしAI活用が進めば進むほど、人間が毎回すべてを目視で確認すること自体がボトルネックになっていきます。そこで重要になるのが、AIが自己修正できる環境です。

発表では、以下のような仕組みの重要性が語られました。

• PHPStan
• PHPUnit
• ESLint
• フォーマッタ
• CI
• 独自の静的解析ルール

「この書き方はやめてほしい」とClaude.mdに自然言語で書くこともできます。
ただ、それはあくまでAIへのお願いです。本当に守らせたいルールは、静的解析やCIに落とし込み、人間が書いてもAIが書いても違反できない状態にする必要があります。

たとえば、

• 特定のFacadeを使わない
• 特定のクラスに依存しない
• 危険な関数を使わない
• 独自のコーディングルールに違反しない

といったものは、PHPStan拡張などで機械的に検出できます。発表者は、AIがNGなコードを書いたタイミングで、その内容を静的解析ルール化していくのがよいと話していました。これはかなりエンジニアリングらしい話だと思います。AIに頑張ってもらうのではなく、AIが安全に頑張れる環境を作る。

これからのAI活用の差は、
「AIを使っているかどうか」ではなく、「AIが完走できる環境を持っているかどうか」
になっていくのかもしれません。

3.サンドボックスで、AIエージェントを安全に動かす

AIがPC上でファイルを読み、コマンドを実行できるようになると、便利さと同じくらい安全性も重要になります。セキュリティ寄りの発表では、コーディングエージェントのサンドボックスについて解説がありました。

同じくスペシャリストのK.Nさん。深い知識を持った実力者です。

AIエージェントは、次のような操作ができます。

• ファイルを読む
• ファイルを書き換える
• コマンドを実行する
• ネットワークに接続する
• Gitを操作する

つまり、設定を誤ると、重要なファイルを消してしまったり、認証情報を外部に送ってしまったりするリスクがあります。そこで出てくるのがサンドボックスです。

サンドボックスとは、プログラムが触れる範囲を制限する仕組みです。
ファイル、プロセス、ネットワーク、権限などの範囲を制御し、安全な囲いの中でAIを動かします。発表で特に強調されていたのは、Claude,mdのような「お願いベース」の制約だけでは不十分だということです。

Claude.mdに「これはしないで」と書いても、それはあくまでAIへのお願いです。
本当に防ぎたい操作は、PermissionsやSandbox、ネットワーク制御、ファイルアクセス制限などで、システム的に防ぐ必要があります。

たとえば、

• ネットワークアクセスを閉じる
• 特定ディレクトリ以外を触れないようにする
• Git操作を制限する
• Pythonなどの実行を制御する
• メール送信や外部連携時には必ず確認を挟む

といった設計が必要になります。

AIエージェントは強力です。だからこそ、便利さだけを見て雑に使うのではなく、どう安全に使うかまで含めて考える必要があります。AI活用を本気で実務に入れようとしているからこそ、このあたりの議論が社内で自然に発生しているのかもしれません。

4.エンジニアだけでなく、全社にも広がり始めている

今回の勉強会では、エンジニア向けの話だけでなく、非エンジニア領域での活用事例も紹介されました。

• 議事録からアクションアイテムを抽出する
• アクションアイテムをチケット化する
• Googleカレンダーの予定を読み取り、その日の予定を要約する
• 問い合わせチャットボットのモックを短時間で作る
• ヘルプデスク対応やトラブルシューティングのナレッジを共有する

といった使い方で、エンジニアが先に試したAI活用が、少しずつ他職種の業務改善にも広がっていて、AIは開発効率化だけでなく、組織全体の働き方を変えるテーマになりつつあります。

部長Y.Sさん。発起人であり、イベントの主導もしていただきました！

5.この勉強会で伝えたい、私たちの開発文化

今回の勉強会を通じてお伝えしたいのは、AIを単なる流行りとして扱っているのではなく、実務の中でどう活かすかをかなり具体的に考えているということです。

現場主導で試す

発表内容の多くは、現場のメンバーが自分の業務課題を起点に試したものでした。

開発フローを自動化したい。
障害分析を効率化したい。
問い合わせ対応を減らしたい。
ナレッジ共有を属人化させたくない。

そうした課題に対して、まず自分たちでAIを使って試してみる。
うまくいったことも、難しかったことも、社内で共有する。

このサイクルがあることは、開発組織として大事な強みだと思っています。

便利さだけでなく、安全性も議論する

AIエージェントは非常に強力です。強力だからこそリスクもあります。

今回の勉強会では、サンドボックス、権限制御、ネットワーク制御、Python実行、Git操作、外部送信といったテーマも扱われました。新しい技術をただ使うのではなく、安全に使うための仕組みまで考える。これは、プロダクト開発にAIを組み込んでいくうえで欠かせない視点です。

AIに任せるために、開発環境を整える

AIに「いい感じに実装して」とお願いするだけでは、再現性のある開発にはなりません。

AIが自己修正できるように、テストや静的解析を整える。
守るべきルールはCIで落とす。
独自ルールは静的解析に落とし込む。
Claude.mdやSkillsでワークフローを整える。

AIを使いこなすには、AIそのものだけでなく、AIが動く環境を設計する必要があります。

人間の役割も問い直す

最後の発表では、AI時代に人間のエンジニアに何が残るのか、という話もありました。

AIは非常に優秀です。
コードも書けますし、レビューもできますし、テストも作れます。

何を解くべき問題とするのか。
何を正しさとするのか。
どこに違和感を持つのか。
どの判断に責任を持つのか。

そこは、まだ人間の役割です。

AIに任せる範囲が広がるほど、人間のエンジニアには、より本質的な判断や設計力が求められるようになります。今回の勉強会は、AIによってエンジニアの仕事がなくなるという話ではなく、エンジニアの仕事の重心が変わっていくということを考える場でもありました。

弊社CTOも登壇。歴戦エンジニアとしての経験も踏まえて話していただきました。

最後に

AIにコードを書かせるだけなら、もう珍しくないかもしれません。しかし、AIが安全に、再現性高く、最後まで走れる開発環境を作るのは、まだまだこれからのテーマです。

AIに任せられることは任せる。
そのための環境をエンジニアリングする。
そして人間は、より本質的な課題設定、設計、判断、価値づくりに向き合う。

私たちは、そういう開発組織を作っていきたいと思っています。

Claude CodeやAIエージェントを触っている方。
開発環境づくりや自動化が好きな方。
AI時代のエンジニアリングを一緒に考えてみたい方。

そんなテーマに少しでもワクワクする方とは、ぜひ一度お話してみませんか。

株式会社セレスのエンジニア募集はこちら！