半年前に決めた仕様の理由を聞かれて、答えられる人が社内にいない。議事録を探しても該当の記述がなく、Slackを遡ると「じゃあそれで」という一行だけが見つかる。決定はされていて、根拠だけが残っていません。
これは委託開発でよく起きる状態です。定例の議事録には結論だけが書かれ、そこに至る検討はチャットで済んでいるからです。そこへ、8月20日にSlackが「Slack Code」の提供を始めました。AIコーディングエージェントがチャンネルの一員として加わり、それまでの議論を把握したうえで実装まで行う機能です。全プランで利用できます。
チャットが「相談の場所」から「実装の入力」に変わるということです。これまで曖昧なまま流していたことが、そのままコードになって出てきます。
Slack Code で何が起きるか
エージェントをメンションすると専用の Code Channel が立ち上がり、実行計画・コードの差分・プレビューがタブに整理されて表示されます。対応するエージェントは Anthropic の Claude Code、Cognition の Devin、GitHub Copilot、Vercel のエージェントなどで、ChatGPT の対応も予定されています。
発注側から見た変化は、道具が増えたことではありません。これまで人間の担当者が読んで解釈していたチャンネルの過去ログが、機械が読む入力になったことです。
読ませる相手が変わると、置いてあるものの意味も変わります。「あとで消せばいい」と貼った顧客リスト、「参考まで」と共有した他社の見積書、雑談に混ざった個人情報。人間相手なら文脈で無視されていたものが、機械にとってはすべて等価な入力です。
1. どのチャンネルを読ませるか
最初に決めるのは範囲です。技術的な設定の話に見えますが、実際には「委託先のエージェントに、自社のどこまでを見せるか」という契約の話です。
実務的には、次の順で線を引くのが扱いやすいはずです。
- エージェントを入れる専用チャンネルを作り、そこ以外には入れない。 既存の相談チャンネルにそのまま追加すると、過去ログ全体が読まれる前提になります。新しく作るほうが、境界の説明が簡単です。
- 顧客の実データを貼らない場所として運用する。 障害調査で本番データを貼る習慣がある現場では、ここが最大の穴になります。貼る必要があるなら、その調査はチャットの外で行う運用にします。
- 委託契約側の取り決めと突き合わせる。 委託先がどのAIサービスに何を渡すかは、秘密保持の範囲に直接関わります。制作・開発の委託でAIツールの利用条件をどう書くかは委託先のAI利用と成果物の取り決めに整理しました。
2. 決定は、チャットの外に書き出す
Code Channel には計画と差分が残ります。これは便利ですが、残るのは「何をしたか」であって「なぜそうしたか」ではありません。
しかも、エージェントが議論を読んで実装できるようになると、人間が決定を書き出す動機がさらに減ります。「チャットに書いてあるから伝わる」が成立してしまうためです。半年後に効いてくるのは、まさにそこで省略された部分です。
対策は仕組みとしては単純で、設計判断だけを別の場所に1行ずつ残すことです。
- 選んだ案と、捨てた案とその理由（捨てた理由のほうが後から効きます）
- その判断が有効な前提条件（利用者数、対象ブラウザ、想定データ量など）
- 決めた日付と、決めた人
リポジトリ内のドキュメントでもWikiでも構いませんが、条件が1つあります。チャットツールの外にあること。 チャンネルはアーカイブされ、ワークスペースは移行され、委託先との契約は終わります。決定の記録がそこにしかない状態は、いずれ必ず失われます。
3. 承認の主体を曖昧にしない
Code Channel では差分がチャンネル上で見えるため、レビューが会話の流れの中で進みます。速さの面では利点ですが、「見た」と「承認した」の境界が消えやすいという副作用があります。
チャンネルで「よさそうですね」と返した発注側の一言が、承認として扱われていないかを確認してください。発注側の担当者はコードの妥当性を判断できる立場にないことがほとんどで、それは当然のことです。問題は、そこに承認の見た目が付いてしまうことにあります。
決めておくのは次の2点です。
- 技術的な承認は誰が行うか。 委託先の中のレビュー担当か、自社の技術責任者か。チャンネルの会話とは別に、リポジトリ上の承認記録として残る形にします。
- 発注側が判断するのは何か。 仕様と受け入れ条件です。動作の確認は発注側の役割ですが、実装の妥当性はそうではありません。AI が書いたコードの受け入れをどう定義するかはAI生成コードの受け入れ方針にまとめています。
この線引きをしないまま導入すると、事故が起きたときに「発注側もチャンネルで見ていた」という話になりがちです。速く回すために導入したものが、責任の所在を曖昧にするために働いてしまいます。
次にやること
まず、委託先とやり取りしているチャンネルを開いて、直近1ヶ月を上から読んでみてください。 そこに顧客の実データや他社の見積書が貼られているなら、エージェント導入の可否以前に、いま整理すべき状態です。
そのうえで、次の定例で「設計判断をどこに残すか」を1つだけ決めてください。 場所さえ決まれば書く習慣は付きます。決まっていないと、どれだけツールが速くなっても、半年後に理由を説明できない状態は変わりません。
委託開発の進め方の整理、AIエージェントを含む開発体制の設計、生成AIを使う際の運用ルール策定については、グリームハブの開発・AI・自動化のご相談で承っています。体制と扱うデータの性質によって進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
