大AI開発時代で起きた鈴木商店の変化

本記事は、2026年3月に名古屋で開催された3社合同AI勉強会での発表をもとに構成したものです。
発表の原案はオズ（CTO）が作成し、ファブ（前村）が登壇しました。
以下はファブの発表をもとに、外部読者向けに編集・補足を加えています。

大AI開発時代で起きた僕らの変化

ぶっちゃけ皆さん、AI開発どんな感じでしょうか。

AIが登場して、僕らシステム開発の環境はかなり天地がひっくり返るほど変わったなと思ってます。

鈴木商店も例外ではなく、いろいろやってきました。

いいこともあったし、まだこの変化に追いつけてないところもある。壁にぶつかって困ってることも正直あります。

今日はそんなリアルな話をしたいと思います。

鈴木商店について

鈴木商店は「挑戦するお客様の力に」を掲げている、大阪・北浜にオフィスを構えるシステム会社です。

一次請けの受託開発をメインにやっていて、言われたものをただ作って納品して終わりではなく、お客様の根本的な課題を一緒に解決していくDX志向の開発スタイルを取っています。

歴史

コーディングエージェントとの出会い（2025年2月）

AI自体は数年前からポツポツ出てきてはいたんですが、
僕たちのシステム開発に対して大きくインパクトを与えたのはコーディングエージェントでした。

コードを自律的に書いてくれるエージェントに触れたとき、
「このペースだと人間がコードを書く時代は終わるな」という予感がうっすらありました。

それから約1年。ほぼコーディングエージェントだけで実装を進め、
僕らはほとんど書いていない状況になっています。

CTOのオズさんも後になって
「まさか1年後に本当にほぼ100%AIが書くことになるとは...」と語っており、
予想以上のスピードで変化が起きています。

AI推進チームの発足（2025年4月）

コーディングエージェントのインパクトを受けて、
「組織的に推進しないとやっていけない」という危機感がありました。

そこで社内に「CAITO（Chief AI Technology Officers）」というチームを立ち上げました。

合議ではなく決定権を持つチームとして、「とにかく早く」AIの波に乗りこなすことを目指したんです。

具体的にやったことは、ChatGPTの全社配布、AI議事録ツールの選定・導入、新しいAIツールが出てきたらすぐ触れられる環境の構築。

それと「月1件以上、AI活用記事を社内ナレッジベース（esa）に投稿しよう」という呼びかけも始めました。

Claude Code 全社導入（2025年6月）

Claude 4とMaxサブスクリプションの登場が転換期でした。

「AIプロバイダーのシェア争いが落ち着く前にノウハウを蓄積しておきたい。価格競争がある今のうちに投資しよう」という判断で、
全社に「Claude Codeの利用料は経費精算OK」と通達しました。（当時はClaudeのTeamプランにClaude Codeが含まれておらず、個人の従量課金でしか使えなかったので、経費精算という形を取っていました。）

2025年6月頃にはesaへの投稿者が全社に広がって、MCP活用など実務適用も加速。

2026年1月頃からは一部メンバーが自発的に高度な活用を始めて、並列タスク運用やスキル作成なんかも出てきました。

現在では約50件のAI活用ナレッジが蓄積されています。

現状

コーディングの90〜100%がAIに

正確にアンケート取ったわけじゃないんですが、エンジニアほぼ全員がClaude Codeを日常的に使っています。

一部のメンバーはCodexをメインにしたり、レビューにCodexを活用したりと、ツールの使い分けも進んでます。

現在ではTeamプランのPremiumシート(Max相当)をエンジニア全員に付与しています。

これは社員としても会社がそこに投資してくれるのは本当に助かるので、めちゃめちゃありがたいと感じています。

そして自分でコードを書くよりも、AIに書かせる割合がほぼ100%を占めるようになりました。

AIファーストなプロジェクト運営

AIの活用が進むにつれて、プロジェクトの進め方そのものも変わってきました。

例えばイシューテンプレートの刷新。数年ぐらい固定化して運用できてたテンプレートをがっつり変えて、「AIに読ませる」「AIにイシューを処理させる」前提の情報設計に切り替えました

• 関連情報・背景の明記
• 仕様セクションの追加
• 受け入れ基準の組み込み

「クロードにこのイシュー取り込んで取り組んで」と言うだけで高いアウトプットが出るレベルを、イシュー側で担保するイメージです。

以前は暗黙知でカバーできていた部分もあったんですが、AIはセッションごとにステートレス（リセット）されるんで、
「何も知らないメンバーが毎回新しく来た」つもりで情報を整理する必要がある。

結果的に僕ら人間にとっても情報が整理されるし、今までふんわりしてたものがしっかり固まるようになった。

ここはウィンウィンだなと感じてます。

コードレビューは「まだ外せない」

AIが書いてAIがレビューして、という状態になってくると、
「コードレビューってもういるの？」という疑問が浮かびます。

現時点での結論は、まだ人間の目は外せない。

• バックエンド: ドメイン観点でのテストレビューは、AIだけでは信頼しきれない
• フロントエンド: ビジュアル面はコードだけではわからない。実際に目で見て初めて気づく問題がある

ただ、レビューの仕方自体はAIファーストに変えていかなきゃいけない。

今まではプルリク単位で都度レビューしていたんですが、これからは2〜3日サイクルでまとまった単位でのモブレビューへ。

開発を細かく止めるのではなく、一気に作って一旦停止、そこまでの完成度をチーム全体で見る。

そういうメリハリのある開発スタイルに転換していきたいと思っています。

社内プロダクトもAIで

AIを活用して社内プロダクトもいくつか作っています。

アサインボード
アサインボードは、誰がどのプロジェクトにいつアサインされているかを可視化するアプリです。

バイブコーディングで作成しました。
以前はExcelで管理しようとしたり、Figmaでボードを作ってみたりしたんですが、「誰がいつ更新するの？」問題がずっと付きまとっていました。

このアプリのおかげで、過剰アサインや空きリソースが一目でわかるようになって、新規プロジェクトの人員計画がスムーズになりました。

(機密情報は伏せております)

このアプリ、うちで一番忙しいはずのメンバーが業務の傍ら1人で作っちゃったんですよ。

手を動かすのはAIがやってくれるんで、「時間がない」「人がいない」を理由にできなくなった。

この事実は社内の価値観に大きなインパクトを与えました。

その他にも、AIエージェント同士がSNSのように投稿・リアクションし合う社内ツール（DevFeed）や、TDDからCI/CD検証まで一気に回すワークフロースキルなど、プロジェクト横断で使える仕組みを社内で共有しています。

課題

ぶっちゃけ課題感はたくさんあります。

技術負債の高速蓄積

機能開発がめちゃめちゃ早くなった分、当然負債が溜まるスピードも速い。そのサイクルに人間が追いつけなくなってきています。

対策としては、
モブレビューを導入してチームで一旦立ち止まって、リファクタリング項目を洗い出す。

それを次の開発計画に組み込む。
「とにかく作って作って」じゃなくて、一呼吸おいてプロダクトを俯瞰するサイクルが大事だなと感じています。

品質管理が追いつかない

開発スピードが上がるとアウトプットも増える。

アウトプットが増えればバグも増える。

AIの開発スピードに人間のレビューが追いつかないのが現実です。

CI/CDでの静的品質ゲートの強化、スプリント単位での品質検証ステップの導入、レビュープロセス自体の再定義。

今までのやり方をAI前提で見直す必要があると考えています。

コンテキストスイッチの負荷

AI開発はめちゃめちゃコンテキストスイッチが発生するんで、その負荷がとにかく大きい。

うちのCTOは8タスクを並列で一気にやってるらしくて、脳みそが焼き切れるんじゃないかと思う。僕はたぶんできないw

早くAIが速くなって、並列開発なんかしなくても十分な生産性が出るようになってほしい。

でもそうなったら、エンジニアとして生き残れるのか？

このジレンマは今まさに向き合っているリアルな感覚です。

人間の方が先にAIに追いつけずに燃え尽きちゃうんじゃないか、
という懸念は念頭に置かなきゃいけない。

過渡期だからこそ慎重に、メンバーのメンタル面も注意深く見ていく必要があると感じています。

将来

組織変化のサイクル

AIによって実装コストが大幅に下がった結果、「何を作るべきか」を考える上流工程の重要性が増しています。

• PM・設計・レビューができる人材の重要性が上がる
• 実装のみのロールは減少していく
• 全員が上流を向くことでチームが圧縮され、余剰リソースが新たな案件に投入される

今まで、実装スキルを極めてからPMや設計に進むというステップがうっすらあったと思うんですが、AIによってその過程が圧縮されると、プロジェクトの回転も今までより速くなっていくはずです。

ロールの壁を越える

今まではPMはPM、フロントはフロント、バックはバックと、ロールが1つ割り当てられるのが普通でした。

でもAIを活用すれば、フロントの人がインフラを見たり、実装者が設計・要件定義に早く関わったりと、越境が現実的になる。

この越境を個人の努力ではなく、組織的な仕組みとして実現していきたいです。

エンジニアでいるために

AIがコードを書く時代になっても、求められるものはあります。

• ドメイン知識: お客様のニッチな課題、業界特有の事情はAIでは拾いきれない
• 専門的な判断力: 品質管理、プロジェクト管理、UX設計など、広くて深い知識
• 課題発見・課題設定の力: AIを使えることより、何にAIを使うべきかを見つける力

AIに対して技術的にトンチンカンなことを言ったら、トンチンカンなものしか出てこない。

入力が悪ければ出力も悪くなる。だからこそ、専門知識やドメイン理解は今まで以上に大事になる。

これを肝に銘じてこの時代に適応していきたいと思っています。

「あえてチームを小さくする」挑戦

実装が高速化したことで、新たな問題も見えてきました。

実装が早すぎて、次に渡すタスクがどんどんなくなっていく。

上流が追いつかないと優先度が低い目先のタスクをアサインしてしまう。

それも高速に消化されて、またアサインして...と繰り返すうちに、今じゃなくていいタスクや他の対応と一緒にやればいい課題まで着手してしまう。

気づかないうちに本質的でない機能開発が増えていき、アウトプットの価値が下がっていく。

僕らの本質は「機能をたくさんリリースすること」じゃなくて、
「価値あるものをリリースすること」のはずです。

AI開発時代では、ボトルネックが実装から上流にシフトしました。

でも上流は人を増やせば早くなるものではありません。

コミュニケーションパスが増えて、かえって鈍足になるかなと思っています。

そこでこれから試みたいのは、メンバーをあえて減らすこと。

• プロジェクトリード: 顧客折衝・要件定義 + バックエンド開発・運用
• プロダクトデザイナー: 要件定義・UIモックアップ + フロントエンド実装
• テックリード: 設計・非機能要件 + フロント/バック/インフラ横断

人数を絞り、ロールの壁をなくすことで、コミュニケーションコストを下げる。

一人ひとりがプロダクトとお客様を深く理解して、「今何をやるべきか」をチーム全員で判断できる体制にしていく。

2026年4月から、一部のプロジェクトでこの体制にチャレンジします。

まとめ

この1年で起きたこと:

• 2025年2月: 初めてコーディングエージェントに触れる
• 2025年4月: AI推進チーム発足、組織的な導入開始
• 2025年6月: Claude Code 全社導入
• 2026年3月: エンジニア全員がAIでコードを書く会社になった

正直な感想として、効率化は確実に起きてます。
でも、それに伴う課題も山積みです。

品質管理、技術的負債の蓄積、人間のサステナビリティ。どれも現在進行形で向き合ってます。

変えていくべきなのは開発手法だけじゃなくて、組織そのものだと考えています。

役割の定義・学び方・システムエンジニアとしての前提

そこから変えていくことで、AIの波に適応できる組織でありたいです。

以上が、AI勉強会での発表内容になります。
鈴木商店では、このようなAI時代の変化を一緒に乗りこなしていく仲間を募集しています！