はじめに
AI Dev Ex 2026に株式会社スマレジはスポンサーとして参加しました。本記事では、そのスポンサーセッションで発表した内容を、スライドに沿って紹介します。
今回のテーマは、個人で始まった生成AI活用をどのように組織へ広げ、さらに自律化へ進めているかです。
「技術は手段」を開発バリューに掲げた組織のAI活用のすべて - Speaker Deck
生成AIによって開発は速く、楽になった
生成AIによって、実装、調査、下書きなどの速度は大きく上がりました。一方で、それはまず個人の作業が速くなったという話です。そのまま組織全体の力に変わるわけではありません。
登壇したのも生成AI関連のイベントですが、各社AI活用はもう使う前提で、どう使うか、どう費用対効果を計測するか、といった次のステップに進んでいます。
これまでの取り組み
まずは弊社スマレジにおけるこれまでのAI活用の取り組みについてご紹介します。
試行と導入
CTO直下の組織で試行し、Devin、Claude、ChatGPT・Codex、CodeRabbit、OpenAI APIを利用した社内ツールなどを、小さく試しながら使える形へ整え、段階的に全社へ広げてきました。
試行錯誤によって、実装や調査の速度が上がり、個人の試行錯誤も活発になりました。特にシニアエンジニアほど効果が大きいという実感もありました。
しかし、日常の開発フローへ自然に入らない、使う人や使い方が曖昧、ノウハウが個人に閉じる、シニアエンジニアがカバーに回りAI利用後の確認へ時間がかかる、といった課題も見えてきました。
つまり、生成AIによって開発は速く、楽になったものの、それはまだ個人の話であり、組織の力には自然に変わらないということです。
この段階では、AI活用が上手い人は個人で生産性を上げているものの、それを放置していても組織全体のAI活用は頭打ちになる、という現実が見えてきました。
まず整えたのは、安心して試せるガードレール
AI活用に出遅れている人にヒアリングを繰り返したところ、入力していいのかわからない、といった恐怖からAI利用を避けている、現状維持バイアスが強いことがわかってきました。
そこで、外部接続、権限、入力してはいけない情報など、決めるべき境界を整理しました。目指したのは、最初から理想的な仕組みを揃えることではなく、まず試せる範囲を明確にし、不安で止まらない土台を作ることです。
具体的には、managed-settings.jsonなどをMDMで配る方式を検討しましたが、弊社の利用しているMDMの場合、運用上難しい部分がありました。そのため、Claudeコマンドを直接使わせず、社内ラッパーから起動する形に変更しました。起動時にGitから最新設定を取得し、利用ルールを共通化しています。
重要なのは、設定ファイルを配ること自体ではなく、「守られる起動経路」を共通化することでした。ガードレールはAI利用を制限するためではなく、AI活用を前へ進めるための土台です。
ちなみにこれらは一例であり、Codexにも似たような仕組みが存在します。
AI利用状況を確認する
利用者が増えていくと同時に整備したのはAI利用状況の可視化の仕組みです。
OpenTelemetryを利用してAIの利用状況を収集し、ダッシュボードで可視化しています。
各AIのSkillsやMCPでも同様のことを検討しましたが、利用するツールや方式が変わるたびに作り直す必要があります。そこで、すでに標準化されつつあるOpenTelemetryを利用し、標準的な観測基盤へ寄せることで、無理なく継続できる形を優先しました。
ただ、まだまだ課題があり、例えばClaudeのWeb利用のチャットなどOTelだけでは対応が難しいものがあったり種別が分かれていることによる全体像の把握の難しさなどが課題です。
開発フローそのものを見直す
ここまでで全社員へのClaude Code or ChatGPTアカウントの配布が完了しましたが、さらにここから、私自身の業務である開発で更なるAI活用に取り組んでいきます。
単発のチャット利用やClaude Code・Codexの利用では、都度人が付きっきりで対話する必要があります。そこで、開発の流れ、実行環境、人の介入まで含めて一から見直しました。
その中で利用したのが、AIエージェントに計画、実装、レビュー、修正のループを与え、複数のエージェントへ指示を出してワークフローを進める「TAKT」です。
これまではRedmineのチケットを人が都度整理して開発を進めていました。これをGitLab Issueベースへ変え、事前の整理にもAIを使い、その後の実行をTAKTへ任せる流れに変えています。
この変更により、複数タスクをキューへ積める、使っている間に作業やレビューが進む、一部既存プロジェクトでも適用できる、若手からシニアまで中心に扱える、といった変化が生まれました。
つまり、仕事の仕方が 朝起きて前日のTAKTの作業内容をレビューする -> MTG等でバックログを整理する -> 夕方にはTAKTに渡して退勤する -> 寝ている間に実装が進む という形に変化していきました。
当時はまだハーネスエンジニアリングやループエンジニアリングといった言葉が生まれていないながらも近い発想を実現していたツールであり、社内で簡単にこれらの概念を実感してもらうことに役立ったと感じています。
直近の取り組み
ここまでは2026年2月頃まで取り組んだ内容で、ここからが直近数ヶ月取り組んだ内容になります。
一番詳しい人だけに依存しない
AIを触っている人は一定数いました。「一番詳しい人」がすべてをキャッチアップし、個人の裁量で先へ進め、使える形にして共有する方法で弊社も活用をを進めてきましたが、それではスケールしづらいということがわかってきました。
AIの進化は速く、追うべき情報も作るべき成果物も増え続けます。一人が詳しいだけでは、組織としてはスケールしないという課題がありました。
例えばskills,MCP,エージェントそれぞれ要望は増えるもののある程度の知識を持って作成できる人は限られます。
そこで現在は、整備するチームと現場に広げるチームの両輪で組織化し、社内での活用を進めています。
AI開発基盤チーム
AI開発基盤チームは、主に開発分野を中心に、個人での開発のスピードアップから、組織の開発基盤としてAIを活用していくためのチームです。知見を共有し、検証を分担し、成果物を一人で抱え込まない体制を作っています。
広げる対象はガードレールだけではありません。業務フローとの統合、社内展開、現場からのフィードバックまで含めて扱います。
チームは4人のエンジニアで構成されています。全員が複数プロダクトを管理しているシニアで構成されており、AI活用を試す上で不要なコミュニケーションがあまり発生しないようにしてAIツールにスコープを絞って検証し、そのあと各チームへの展開を行います。
重要なのは、AIに詳しい専任者だけではなく、メリットを強く感じている現場のエンジニアが試すことだと考えており、一人で複数プロダクトを持っている状態だとよりAIによる生産性の向上の恩恵を感じやすく、活用が進むと考えています。
業務推進チーム
もう一方の業務推進チームは、現場への展開、フィードバックの収集、業務フローへの統合、実運用での改善を担います。
AI開発基盤チームがAI関連の調査、知見の共有、ガードレールなどの整備、共通基盤づくりを担当し、業務推進チームが現場への展開と改善を担当します。整備するチームと現場に広げるチームを分け、両輪で進めています。
生成AIが登場したことで、「全部エンジニアがAIを使って進めれば効率的ではないか」という発想が生まれ、そこから業務推進チームが誕生しました。
しかし、AI活用はコーディング支援で終わりません。会社の前提と業務導線に合わせて、道具の使い方そのものを変えていく必要があります。
その先では、組織のミドル層が担っている進行や調整をどのように変えるかという課題も出てきます。AIが人を置き換えること自体が目的ではなく、実装能力ではなくシニアの判断をどうスケールさせるかという点が重要です。
Human in the loopからHuman on the loopへ
現在は、人がプロセスの中に入り、AIの判断を補助・修正するHuman in the loopが中心です。
これから弊社スマレジでは、業務内容に応じてAIがプロセスを自律的に実行し、人は設計、監視、最終判断を担うHuman on the loopへ移していきます。
人が毎回AIへ依頼して結果を見る状態から、AIが自身でトリガーとなり作業を完結させる状態への移行です。
もちろん完全に移行することは難しいと思いますが、コア業務とノンコア業務を分別した上で、ノンコア業務の大半をHOTLに移行を進めていく予定です。
Human on the loopに向けた取り組み
現在は、次のようなエージェントや仕組みを試しています。
- 開発への仕様確認の初動、AI検索、エンジニアへの問い合わせ整理、ドメイン知識の参照経路を整える「AI仕様回答くん」
- MR差分をもとに検証観点を出し、レビューやQA観点の抜けを減らし、シニアの確認観点を再利用する「QA-Agent」
- 記憶や学習の機構を持ち、OSSのAgentを利用して、各部署の業務改善に合わせて育てる「Hermes Agent」
このように自作エージェントを作成しつつ、AIエージェントの管理を個人からチームへと移譲しつつ、ループから人間が離れていく方向性を模索しています。
これによってAI活用が個人に閉じずにスケールするのではないかと考えています。
生成AIは量をスケーリングするが、質はスケーリングできない
生成AIによって速度や作業量が増えても、価値の判断は別に設計する必要があります。
スマレジの開発バリューは「技術は手段」です。もちろんAIも手段です。AIで何かをすること自体が目的ではなく、技術を使ってプロダクト価値をどう高めるかが重要です。
そのため、AI導入をゴールにしない、速く作ることだけを成果にしないという考え方を取っています。AIは調査や実装を速くし、判断に使える情報を増やし、人が深く考える時間を作るための手段です。
速くコードが書けても、それだけではアウトカムや生産性の向上にはつながりません。実装、調査、下書き、たたき台づくりは速くなりやすい一方で、ユーザーが何を求めているか、要求定義が十分にできているか、品質を落とさず届けられるか、QAや運用まで含めて良くなったかは、別に守る必要があります。
AIで浮いた時間を現場理解へ再投資する
AIで速く作る会社ではなく、AIでより深く理解する会社を目指して進みたいと考えています。
コードを書く時間を圧縮し、弊社はPOSシステムの企業なので、エンジニアが現場や店舗へ出向く時間へ変える。仕様をビジネスサイドやCS担当者へ聞くのではなく、自身で確認する時間へ変える。コードレビューだけではなく、チームで要求定義を深める時間を増やす。そして、より多くのプロダクトに関わる余白を確保し、広い視座で会社全体の課題解決へつなげます。
まとめ
スマレジにとってのAI活用は、個人活用から組織へ、組織から自律へ進む取り組みです。
まず、ガードレール、業務フローの整備、AI開発基盤チームによって、個人技を基盤へ変えます。次に、Loop Engineering、Human on the loop、レビューや検証の観点、シニアの見立てを通して判断を広げます。そして、現場理解、要求定義、品質へつなげます。
コードを書く速度を上げることではなく、プロダクト価値に変える速度を上げること。AIで速くなった分を、現場理解とプロダクト価値へ再投資することが、スマレジらしいAI活用だと考えています。
