KT｜AI×開発組織設計

フリーランスエンジニア 大規模SaaSで新規機能の設計・技術判断 AI前提（Claude Code / Codex）の開発導入・組織設計 技術顧問・壁打ち相談歓迎｜DMにてご連絡ください

[KT｜AI×開発組織設計 @neurostack_0001]

技術顧問として入っている会社で、QAチームにClaude Codeを導入してテストケース生成を自動化した話を書きました。

スプリント後半にQAがボトルネックになっていたので、Claude CodeのSkills・サブエージェント・JIRA MCPを組み合わせて、QAが /generate-testcases Sprint-5 と打つだけでテストケースが自動生成される仕組みを作った。

設計のポイントは「Skill = QAの入口 + テスト観点」「サブエージェント = 安全な実行環境」という責務分離。Skillにワークフローとテスト観点を集約し、サブエージェントはdisallowedToolsでコード変更を禁止するだけ。テスト観点を更新したいときはSkillだけ修正すればOK。

導入してみて一番変わったのは、QAがゼロからテストケースを作るのではなく「AIが出した叩き台を調整する」作業に変わったこと。副次効果として、受け入れ条件を詳細に書く文化がチームに根付いた。

https://t.co/ZU0tQL8Brb

[KT｜AI×開発組織設計 @neurostack_0001]

Google WorkspaceのGemini統合、地味に実用度が高い。

3/10に発表された新機能のポイント:

- Docs: 「議事録からニュースレター作って」みたいな指示で、Drive内のファイルを参照して下書き生成。文体統一機能も追加
- Sheets: 「Fill with Gemini」で100セルの手入力が9倍速に。Google検索からリアルタイム情報も引ける
- Slides: スライドのトーンやデザインを既存資料に合わせて自動生成

注目は「複数アプリ横断でデータを引っ張れる」点。メール、ドキュメント、Webの情報をまとめて処理できるのは、NotionAIやCopilotにはない強み。

判断: 使う（Workspace課金済みなら）

Google AI Ultra/Pro向けベータで英語圏から展開中。日本語対応はまだだけど、Sheets→Fill with Geminiだけでも試す価値あり。

https://t.co/48tJthQMQr

[KT｜AI×開発組織設計 @neurostack_0001]

正直に言うと、AIツールを使いこなせない人には共通点がある。

1年以上AI駆動開発してきて見えたパターン：

「AIに全部やらせよう」か「AIなんて信用できない」の両極端な人ほど、結局うまくいってない。

最新の調査でもAIコードはヒューマンコードの1.7倍バグを含むというデータが出てる。4回に1回はミスする。これが現実。

じゃあ使えないのか？違う。

使いこなしてる人は「ここはAIに任せる、ここは自分で見る」の線引きが明確。AIを万能ツールじゃなくて、仕様と限界があるライブラリとして扱ってる。

具体的にダメなパターン：
- プロンプトが曖昧（「いい感じにして」で終わり）
- 生成コードをそのままコピペ
- テストもレビューもAI任せ
- コンテキストを渡さずに使う

逆に伸びる人は、AIの出力を「下書き」として扱って、自分の判断でブラッシュアップしてる。

結局、AIは人間の判断力を代替しない。判断力がある人ほどAIの恩恵を受けられるという、ちょっと皮肉な構図。

[KT｜AI×開発組織設計 @neurostack_0001]

AI投資の相談を受けるたびに、同じパターンで転ぶ会社を見てきた気がするので整理してみた。

AI投資で経営者がやりがちな判断ミス 5選

①「まずツールを買う」から入る
→ PwCの調査で56%の企業がAIから収益改善ゼロと回答してる。大体これ、業務課題より先にツールを選んでるケースが多い。順番が逆なんだよね

②情シスやDX推進室に丸投げ
→ 「AIのことはよくわからんから任せた」で始まるプロジェクト、体感で8割うまくいってない。現場の業務を知らない部門がAIの使い道を決めるのは無理がある

③PoCで満足して止まる
→ MITの調査だと、企業が作ったAIツールのうち本番まで到達するのはわずか5%。「やってみました」で終わる検証が多すぎる。最初から「何が確認できたら本番に進む」を決めておかないと永遠にPoC

④ROIを既存事業の物差しで測る
→ 「3ヶ月で投資回収」みたいな基準を当てはめると、ほぼ全部のAIプロジェクトが失敗に見える。学習コストや業務変革の時間軸が違うから、半年〜1年で「判断の質が変わったか」を見るほうが現実的

⑤全社展開を急ぐ
→ 1部門で小さく成功した事例を、いきなり全社に広げようとして頓挫するパターン。部門ごとに業務の構造が違うから、横展開より「各部門で小さく始める」を繰り返すほうが結局早い

共通してるのは、AI投資の判断に「技術の知識」より「自社の業務理解」が足りてないこと。ツールの目利きは外に頼めるけど、どの業務にAIを入れるかは中の人にしか決められない。

[KT｜AI×開発組織設計 @neurostack_0001]

1年前まで「開発チーム」といえば、だいたいこうだった。

バックエンド3人、フロントエンド2人、QA1人、PM1人。7人チームで2週間スプリント。タスクを分割して、それぞれがパートを持って、PRを出し合う。

今、AIエージェントを本格的に組み込んでいるチームは、全然違う形になってきている。

エンジニア2人、PdM0.5人、デザイナー0.5人。この構成で、従来の7人チームと同等のアウトプットを出している現場がある。Gaudiyの事例では、少人数チームがAI駆動開発で他チームと同じパフォーマンスを実現した。

Gartnerの予測だと、2030年までに80%の組織が大規模チームからAI補強型の小規模チームに移行するらしい。実際、AIを深く組み込んだチームはサイクルタイムを40〜70%短縮している。

Before：
人数 = 開発力。足りなければ採用する。
役割は固定。バックエンドの人はバックエンドだけ。
チーム間の調整コストは「仕方ないもの」。

After：
人数は少なく、一人の守備範囲が広い。
AIエージェントが「もう一人のチームメンバー」として実装を担う。
調整コストが激減する代わりに、一人ひとりの判断力への依存度が跳ね上がる。

面白いのは、コパイロット関連の支出の86%がエージェントベースのシステムに投入されていること。補助ツールじゃなくて、自律的に動くエージェントに投資が集中している。

ただ、少人数化で見落としがちなリスクもある。

属人化が深刻になる。2人チームで1人が抜けたら、チームの半分が消える。AIがコンテキストを保持してくれる部分はあるけど、意思決定の文脈まではカバーしきれない。

チームを大きくすることが正解だった時代から、チームを小さく保つことが強みになる時代へ。でもそれは「少人数でも回せる仕組み」を先に作れた組織だけの話で、人を減らせばいいという単純な話じゃない。

[KT｜AI×開発組織設計 @neurostack_0001]

最近よく聞くのが「うちCTOいないんですけど、AI導入どこから手つけたらいいですか」って相談。

正直、この質問が出る時点で組織としてはまっとうだと思ってる。少なくとも「何がわからないか」に気づいてるから。

WEFの調査で、AI関連の意思決定者としてCEOを挙げた企業が72%に達したらしい。去年は3分の1だったのに。これ、CTOがいる会社でもAI戦略はもはや技術部門だけの話じゃなくなってるってことなんだよね。

じゃあCTO不在の組織はどうするか。

ありがちなのが「AIに詳しい人を採用しよう」って動くパターン。でもこれ、順番が逆で。まず決めるべきは「どの業務判断をAIに任せたいか」であって「AIで何ができるか」じゃない。

ある50人規模の会社で見たケースだと、経理のベテランが月次で3日かけてた異常値チェックを、まず1つだけAIに置き換えた。技術的にはたいしたことない。でもこの判断ができたのは、業務の中身を知ってるその経理担当者自身だった。

CTO不在でも回る組織のAI導入って、実は「業務を一番知ってる人が、小さく試して、結果を経営に報告する」ってサイクルが核になってる。

技術の目利きは外部顧問やパートナーに頼めばいい。でも「この業務のここが判断のボトルネックだ」って見立ては、中にいる人にしかできない。

CTOがいないことは、AI戦略の不在を意味しない。問いたいのは、自社の業務判断のどこにAIを挟むかを、今の組織で誰が考えているか、ということだと思う。

[KT｜AI×開発組織設計 @neurostack_0001]

GTC 2026、地味にヤバいの来た。

NVIDIAが「DGX Station GB300」を発表。
デスクトップサイズで748GB共有メモリ、20ペタフロップス。
1兆パラメータのモデルを手元で動かせる時代が見えてきた。

もう一つ注目は「NemoClaw」。
エージェントAIをセキュアに動かすためのOSSスタック。
ガバナンス・制御・プライバシーを組み込んだランタイムで、企業がエージェントを本番投入する障壁がかなり下がりそう。

個人的な判断：
・DGX Station → 様子見（価格次第だけど、ローカルLLM勢には革命的）
・NemoClaw → 使う（エージェント運用のセキュリティ課題は今まさに困ってる領域）

ジェンセンの「トークンがAIの基本単位」という発言も印象的。
インフラからアプリ層まで全部トークン経済圏で設計する思想が明確になった。

https://t.co/z74lrk1EFZ

[KT｜AI×開発組織設計 @neurostack_0001]

ぶっちゃけ、AI生成コードで一番怖いのはバグじゃなくて「理解負債」だった。

CodeRabbitの調査で、AI生成のPRは人間の1.7倍の問題を含むって話は有名。48%に検出可能なバグがあるのも知ってた。

でも実際に半年運用して直面したのは、もっと地味で根深い問題。

「このコード、なんでこう書いてあるの？」に誰も答えられない。

AIが生成→動く→マージ→半年後にバグ。
修正しようとしても、設計意図がわからない。
結果、AIに「直して」と投げる→また意図不明のコードが増える。

@ ITが「Doom Loop」と呼んでるやつ、まさにこれ。LLM修正の無限ループ。

先週のFortuneでも、AIエージェントがDB全消去した事例が報じられてた。「動くから大丈夫」の先にある崖は、想像以上に近い。

今やってる対策：

1. AI生成コードには必ず「設計メモ」を残す
コメントじゃなく、PRの説明に「なぜこの設計か」を書く。未来の自分への手紙

2. 「説明できないコードはマージしない」ルール
レビューで「これ何してる？」に答えられなければ差し戻し

3. 週1で「AIなしリファクタリング」
自分の手でコードを読み直す。理解負債の返済日

技術負債は可視化できる。でも理解負債は気づいた時にはもう手遅れ。

AI駆動開発の本当の敵は、バグじゃなくて「わからないまま動いてるコード」だと思う。

[KT｜AI×開発組織設計 @neurostack_0001]

これ言うと怒られそうだけど、CLAUDE.mdやcursorrulesを丁寧に書いてる人ほどAIの生産性が低い可能性がある。

ETH Zurichの研究（138リポジトリ、5,694PR検証）で判明した事実：

・AI生成の指示ファイル → 成功率3%低下、コスト20%増
・人間が書いても → 成功率4%上がるがコスト19%増

要は、指示ファイルが「AIの足を引っ張ってる」ケースが大半。

理由は単純で、AIエージェントは従順すぎる。
不要なルールでも律儀に守ろうとして回り道する。

特に無駄なのが：
- ディレクトリ構造の説明（AIは自分で探索できる）
- アーキテクチャ概要（コード読めばわかる）
- /initで自動生成した内容

書くべきは「AIが自力で発見できない情報」だけ：
- 特殊なビルドコマンド
- テスト実行の罠
- プロジェクト固有の暗黙知

300行超えてるなら、削る作業をしたほうがいい。

「何を書くか」より「何を書かないか」の設計が、AI活用の次のステージ。

[KT｜AI×開発組織設計 @neurostack_0001]

AIエージェントを3ヶ月ガチで使い込んでわかったこと。

「AIコーディング＝コード補完」の時代は終わった。

2026年、エージェント型AIは"指示待ち"じゃなくて"自走"する。
タスクを渡したら、調査→実装→テスト→PRまで一気通貫で動く。

実際にClaude Codeをエージェントとして使ってるけど、体感で開発速度は3〜5倍。
Anthropicの社内データだと、Claude Codeのコードの約90%はClaude Code自身が書いてるらしい。

ただし、うまく使うコツがある。

1. タスクは「小さく切って渡す」
→ 大きすぎると迷走する。PRサイズを意識

2. git worktreeで並列セッション
→ 複数機能を同時に開発できる。これ知らない人多い

3. レビュワーとして関わる
→ 実装者からレビュワーに役割シフト。コード読む力がより重要に

「AIがあれば誰でも開発できる」は半分正解で半分不正解。
AIエージェントは既存スキルの増幅器であって、代替じゃない。

設計力・レビュー力がある人ほど恩恵がデカい。

[KT｜AI×開発組織設計 @neurostack_0001]

開発組織のAI投資、従来の測り方じゃもう計れないなと感じることが増えた。

ここ半年で何社かのAIツール投資を棚卸しした。エンジニア1人あたり年$2,000〜3,000、15人なら年500万近い。「で、効果は？」と聞くと返ってくるのが「PR数増えました」「コード書くの速くなりました」。

これ、どこも似た話なんだけど、そもそもエンジニアがコーディングに使う時間は業務全体の14%。その14%が倍速になったところで、組織のアウトプット全体にはあまり響かない。

DXの調査で86%のエンジニアリングリーダーが「どのツールが一番効いてるかわからない」、40%が「ROIを説明するデータ自体ない」と答えてる。MITの調査だと生成AIプロジェクトの95%が半年以内に財務リターンを出せていないらしい。

うまく回ってるチームは、測ってるものが違う。コード量じゃなくサイクルタイム。バグ修正件数じゃなく混入防止率。人を増やさずに広げたスコープ幅。

「何時間浮いたか」より「同じ人数で何をどこまで届けられるようになったか」。来期の予算会議でCFOに「で、結局いくら儲かったの？」と聞かれたとき、この物差しが手元にあるかどうかで勝負が分かれると思う。

[KT｜AI×開発組織設計 @neurostack_0001]

最近、顧問先でよく話すのが「AIに渡すコンテキスト」の話。

AIに仕事を任せるために「言語化」が必要になったもの 5選

①コーディング規約の「なぜ」
→ 「こう書け」だけだとAIが別解釈で書き始める。理由まで添えて初めて意図通りになる

②設計上「やらないこと」の記録
→ 過去に試してダメだったパターン。これがないとAIが同じ地雷を踏む。ADRに残すのが一番手軽

③ビジネスロジックの業務背景
→ 「なぜこの条件分岐があるか」はコードから読めない。業務知識の言語化が一番難しくて一番効く

④レビュー観点の明文化
→ ベテランの「ここは絶対見る」を書き出さないと、AIレビューも人のレビューもザルになる

⑤プロジェクト固有の制約と前提
→ CLAUDE.md、AGENTS.md、.cursorrules。各AIツールでコンテキストファイルが標準化されてきた

面白いのは、AIのために書いたドキュメントが新メンバーのオンボーディングにもそのまま効くこと。暗黙知の棚卸しって、やってみるとチーム全体の底上げになる。

[KT｜AI×開発組織設計 @neurostack_0001]

半年AIでデバッグしてわかったけど、「エラー出たからAIに投げる」だけだと逆に遅くなる。

調査によると、AI生成コードのデバッグは人間が書いたコードより時間がかかると感じてる開発者が45%もいる。

原因はシンプルで、情報の渡し方が雑だから。

俺が試行錯誤して辿り着いたデバッグの型がこれ。

1. エラーログは「全文」を渡す
要約すると精度が落ちる。スタックトレース全文を渡すだけで診断精度が75%上がるというデータがある。ターミナルならパイプで直接流し込める。

2. 「再現手順」をセットで伝える
「このエラー直して」だけだと、AIは推測でコードを書く。「○○した後に△△すると発生」まで伝えると、80%のバグが3往復以内で解決する。

3. 修正前に「計画」を出させる
いきなりコード修正させると、1つ直して2つ壊す。「まず原因の仮説を3つ出して」と挟むだけで、的外れな修正が激減した。

4. 修正後に必ず「検証」させる
AIに修正させて終わりじゃない。「修正が既存の動作を壊してないか確認して」まで依頼する。再現→特定→修正→検証のループをAI内で完結させるのがコツ。

要は「エラー投げて祈る」から「再現→仮説→修正→検証のループを回す」に変えるだけ。

これだけでデバッグ時間が体感半分になった。AIは優秀な相棒だけど、「何を見せるか」で性能が全然変わる。

[KT｜AI×開発組織設計 @neurostack_0001]

この半年で「AI入れたけど思ったほど...」って相談が急に増えた。

見落としがちなAI導入の落とし穴 5選

①コードは増えたのにリリースが遅い
→ AIの生成スピードにレビューやQAが追いつかない。前工程だけ速くしても後工程が詰まるのは製造業と同じ構造

②生産性の計測がバイブスになってる
→ Bainの調査だと実質コード増は10%程度で、品質指標は軒並み悪化。「速くなった気がする」と成果は別物

③社内コンテキスト不在で標準化が壊れる
→ 自社のアーキテクチャを知らないAIが書いたコードの整理係が増えてる。導入前より手間かかってない？って話

④ガバナンスなしで全社展開してしまう
→ セキュリティもIP管理も曖昧なまま「便利だから」で広がって、あとから巻き取れなくなるパターン

⑤使い方のバラつきが大きすぎる
→ まだ業界標準がないから個人任せになりがち。同じチームでもAIの恩恵に10倍差が出てたりする

ガートナーが「2026年までにAIプロジェクトの30%が放棄される」って言ってるけど、入れること自体がゴールになってないか、一回見直してみるのはありだと思う。

[KT｜AI×開発組織設計 @neurostack_0001]

経営会議でAIの話をすると「面白いね、検討しよう」で終わって、次の会議ではもう忘れられてる。

何社か見てきて気づいたのは、技術側がAIを「提案」として持っていくからこうなるということ。

やり方を変えてみた。AIの議題を「業務課題に対する改善案」として出す。ツール名は出さない。コスト削減額と工数削減の見込みだけ並べる。

BCGが今年1月に出した調査だと、CEOの72%が「AIの意思決定は自分がしている」と答えてる。経営層はAIに前向きなんだよね。

一方でIBMの数字を見ると、AI施策の75%が期待したROIに届いていない。

このズレ、技術側が「AIで何ができるか」を語りすぎてるところにあると思う。

経営層が判断に必要なのは3つだけ。

・いくらかかって、いくら浮くのか
・いつから効果が出るのか
・最悪のシナリオは何か

このフォーマットで議題を組み直したら、「検討しよう」が「来月からやろう」に変わったケースがいくつかあった。

まだ足りてないのは、導入後の効果測定を次の経営会議にフィードバックする仕組み。ここまで回せてる会社は正直少ない。技術責任者がやるべきは、AIを売り込むことじゃなくて、経営判断に必要な数字を揃えることなのかもしれない。

[KT｜AI×開発組織設計 @neurostack_0001]

1年以上AI駆動開発してきて、ようやく「ここは任せる、ここは自分でやる」の線引きが固まってきた。

結論から言うと、「検証しやすいタスク」はAIに任せていい。「検証コストが高いタスク」は人間がやるべき。

AIに任せて正解だったもの：
- ユニットテスト生成（実行すれば正誤がすぐわかる）
- 型定義・インターフェース設計（コンパイラが検証してくれる）
- リファクタリング（テストが通れば正義）
- ボイラープレート・CRUD実装

逆に、任せて痛い目を見たもの：
- ビジネスロジックの設計（「動くけど仕様と違う」が一番怖い）
- セキュリティ周り（Georgetown CESETの調査でAI生成コードの45%に脆弱性）
- アーキテクチャの意思決定（AIは「今動くコード」は書けるけど「半年後に破綻しない設計」は苦手）
- エラーハンドリング（正常系は完璧、異常系がザル）

最近意識してるのは「Steer or Delegate」の使い分け。

Steer（操縦）= リアルタイムでAIを見ながらガイド
→ ビジネスロジック、複雑な状態管理

Delegate（委任）= 仕様だけ渡して結果だけ確認
→ テスト、型定義、定型コード

「全部AIに任せる」でも「全部自分で書く」でもなく、タスクの検証可能性で判断する。

これが今の自分の基準。みんなはどこで線引いてる？

[KT｜AI×開発組織設計 @neurostack_0001]

この半年で「これもういらなくない？」って思うことが増えた。

AI時代に不要になった開発プラクティス 5選

①コード行数で進捗を測る
→ エージェントが1日で数千行書くのに行数を追いかけてもしょうがない。「仮説をいくつ検証できたか」に切り替えたチームから成果が出てる

②全コード手書き前提のスプリント計画
→ 実装の見積もりが半分以下になってるのにスプリントの組み方は3年前のまま、という現場がかなり多い

③新人にまず「コード写経」をさせる
→ 写経で身につくのは構文知識。今は仕様を言語化してエージェントに実装させるほうが、設計力が早く育つ

④詳細実装設計書の事前承認フロー
→ 30ページの設計書を3部署回すより、プロトタイプを動かして合意取るほうが早いし正確。設計書は後追いでいい

⑤定型コードのペアプロ
→ CRUDやテスト生成を2人で書く意味はもうない。ペアプロは設計判断が割れるところに絞ったほうが効く

全部「やめる」というより「目的に合わせてアップデートする」が正確かな。慣性で残ってるプラクティス、チームに一つはありそう。

[Franny Philos Sophia @cactaceae]

これ面白くて、みんなエンジニアの価値がわからないから安い人から決まっていく

[いとゆ @itoyu1192]

何に価値を置くかっていうのは全く持ってその通りだから、実は仕事の再定義が必要なんですよね

コード書くだけの人と、コードをレビューする人と、QAで品質保証する人では求められるものが全然異なるし、とうぜん対価も変わるので

[KT｜AI×開発組織設計 @neurostack_0001]

最近、エンジニア採用の面談で「この人、年収いくらで出すのが正解なんだろう」って悩む頻度が明らかに増えた。

ある会社ではAIエージェントを使いこなすミドル層に年収200万上乗せのオファーを出した。別の会社では、同じスキルセットのシニアに去年と同額を提示したら辞退された。

何が起きてるかというと、エンジニアの市場価値の「物差し」自体が変わってきてる。

米国ではAI/ML関連スキルを持つエンジニアに12%の年収プレミアムがつく一方で、Big Techのジュニア採用は25%減。日本でもDeNAがAIスペシャリスト枠の新卒に600〜1000万を提示してる。

「コードを書ける」の価値が下がって、「AIを使って何を生み出せるか」に値段がつき始めてる。

ただ、CTOからすると結構厄介な話で。

今いるメンバーの市場価値をどう再評価するか。AIを使いこなせる人に報酬を寄せると、そうでない人との格差が開く。かといって一律に上げる余裕はない。

もっと言うと、「AIを使いこなせる」の定義がまだ固まってない。プロンプトが上手い人なのか、AIの出力を正しく検証できる人なのか、AIを前提にアーキテクチャを設計できる人なのか。

エンジニアの市場価値って、結局その組織が「何に価値を置くか」の写し鏡なんだよね。

自社のエンジニア評価制度、最後に見直したのいつだろう。その物差し、まだ今の市場に合ってる？

[KT｜AI×開発組織設計 @neurostack_0001]

半年前まで「APIを叩くスクリプト」を手書きしてた自分が馬鹿みたいに思える。

MCPを実務に組み込んで3ヶ月。正直、開発の景色が変わった。

何が変わったかというと、AIが「外の世界」を直接触れるようになった。

以前はClaude Codeに「GitHub見て」と言っても無理だった。Slack通知もDB確認も全部コピペで橋渡し。AIは賢いけど、情報の孤島だった。

MCPを入れてからの変化：

1. PR出したら自動でレビュー準備が走る
Claude Code × MCP × GitHubの連携。差分取得→関連コード調査→レビューポイント整理まで自動。LINEヤフーのチームは週6時間の工数削減を実現してる。

2. 「調べて→まとめて→投稿して」が1コマンド
Web検索→WordPress投稿→Twitter告知。以前は3つのAPIを個別に叩くスクリプトを保守してた。MCPサーバーにしたら、AIが必要な時に必要なツールを選んで呼ぶ。

3. 自作MCPサーバーが資産になる
一度作れば、Claude CodeでもCursorでもWindsurfでも使える。ベンダーロックインなし。今やMCPサーバーは9,000以上。SaaS大手の70%がリモートMCPを提供してる。

ただし注意点もある。
MCPエコシステムで脆弱性も見つかってる。信頼できないサーバーは入れない、権限は最小限に。便利さとセキュリティはトレードオフ。

「AIは賢いけど手足がない」時代は終わった。
MCPはAIに手足を与えるプロトコル。使わないのは、スマホ持ってるのにアプリ入れないのと同じ。