AI と共創する開発文化 - AI ファーストな開発スタイルの先へ

最終更新日： 2026年06月01日投稿日： 2026年06月01日

こんにちは、ヌーラボで Principal Platform Engineer として働く iwa (@mananyuki) です。日々ヌーラバーが専門性を発揮し、価値を生み出せる環境づくりに邁進しています。最近は AIX Team のリードに就任し、ヌーラボにおける AI Transformation 戦略を考え、実践しています。一方で、家庭では率先していぬと赤ちゃんのおもちゃになり、笑顔のあふれる家庭づくりに日々取り組んでいます。

さて、ヌーラボのエンジニアブログでは、ちょうど 1 年前に「AI ファーストな開発スタイル」を宣言する記事を公開しました。あれから 1 年が経ち、開発現場で何が変わったのか。このブログは、私たちなりにその問いに答えるものです。

たとえばこんな問いです。あるチームだけ AI ネイティブで、あるチームはそうではない。その差はどこから生まれるのか。答えは「使えるツールが揃っているか」ではなく、もっと別のところにありました。

観察: AI ネイティブなチームと、そうでないチーム

ヌーラボには複数の開発チームがあります。なかでも AI インテグレーションチームと Platform Engineering チームは、AI ネイティブな開発フローへの移行が早く進んでいるチームです。

両チームに共通するのは、ビジョン駆動の強いリーダーシップでした。実際、両チームとも Principal Engineer が技術リーダーを務めています。技術的な視座が高く、組織横断で影響力を発揮できる立場にあるからこそ、AI のように評価・検証のサイクルを早く回す必要がある技術にも、いち早く飛び込めるのだと感じています。職位そのものが鍵というわけではありません。視座の高さと、組織のために検証する責任感を持ち合わせた人が技術リーダーであるとき、AI ネイティブな開発フローは根を張りやすくなるという構造です。

そしてその下に、Agentic Coding に関心を持つメンバーが集まり、コードベースに対する強いオーナーシップを持って LLM 主導の開発を自発的に取り入れていく。これが、両チームに共通する姿でした。

一方で、新しいプロダクトを作るチームや、プログラミングを純粋に愛するエンジニアの集団でも、必ずしも AI ネイティブに移行しているわけではありません。新規開発でこそ AI を最大限活用できそうなのに、そうなっていないこともあります。

そこから見えてきたのは、シニア・プリンシパル層のソフトウェアエンジニアほどアダプションが早く、なかでもビジネスと接続している人ほど、AI ネイティブな開発フローに飛び込むのが早いという傾向でした。

経験を積んだエンジニアほど、自分のコードベースに深いオーナーシップを持っています。だからこそ AI に任せる前に「何を検証すべきか / どこまで任せて良いか」を問い続ける。それは AI 時代のプロフェッショナリズムの一つの形だと、私はそう感じています。

診断: 「AI ツールがない課題」ではない

ここまでの観察から、私たちは何を診断したか。最初に向き合った事実は、ヌーラボでは開発のためのツールがすでに揃っているということです。

少し以前の私たちは、Amazon Bedrock や Gemini Enterprise Agent Platform (旧 Vertex AI) を LLM バックエンドとして採用し、Claude Sonnet や Gemini を無制限に使い放題にしていました。それでもチーム間に差は出ます。むしろ、「使い放題」がユーザー自身にコストを意識させてしまい、サブスクリプションモデルよりも心理的障壁が大きいことが分かってきました。

だから今は、目的に応じてサブスクリプション型のサービスを組み合わせる方向に舵を切っています。GitHub Copilot や Cursor のように複数モデルを定額で扱えるコーディングエージェントから試行を始め、コストパフォーマンスを評価しながら、最終的に Claude Team や ChatGPT Business といった定額プランを用いて Claude Code と Codex を使う形に落ち着きました。

つまり、足りないのは「ツール」ではなく「使いこなす方法論」なのです。これが、私たちが現場から得た診断です。AI ツールを「とりあえず配る」「無制限に使わせる」だけでは、活用は始まりません。何のために、どう使うかを言語化し、チームで共有し、実践を通して磨かない限り、ツールは机の上の道具のままです。

偶然にも、私たちの診断と重なる表現を DORA も使っています。“State of AI-assisted Software Development 2025” は、“Successful AI adoption is a systems problem, not a tools problem” (AI 採用の成否は、ツールの問題ではなくシステムの問題である) と述べています。現場の感覚と業界の標準フレームが、ここで重なっていました。

冒頭で触れた 1 年前の記事は、「AI ファーストな開発スタイル」を宣言するものでした。あれから 1 年、私たちの問いは「配ったあとの方法論」へと移っています。

処方: 多モデル戦略と Platform Engineering の発想

この診断から、私たちは二つの処方を導きました。多モデル戦略と、AI 戦略への Platform Engineering の発想の取り込みです。

多モデル戦略は、単一ツール・単一モデルですべてを済ませず、目的に応じて使い分ける考え方です。Claude Code と Codex を中核に据え、エージェントネイティブな開発方法論を実践しやすい環境、コードベース理解の支援、コードレビューの伴走、ナレッジと言語の壁を越える支援などを組み合わせます。モデルの優劣は流動的なので、各モデルプロバイダーが提供する公式ハーネスは、性能を最大化する観点で重要です。

開発方法論の探究は、それ自体が日進月歩です。私たちは特定の方法論に縛られず、その時々で最良のやり方を検証・評価しやすい仕組みを整えることを前提にしています。たとえば最近では Structured-Prompt-Driven Development のような方法論も登場しています。新しい型が出てきたら、まずチームで試して、効くものを残し、私たちの開発プロセスを最適化する取り組みを続けています。

コードベース理解の支援は、私たちが特に効果を実感している領域です。最初は 2025 年春に Cline などのコーディングエージェントを使ってコードベースを読み解く検証から始めましたが、コストとコンテキストウインドウの制約がボトルネックになりました。試行錯誤を経て最終的に、Devin の DeepWiki と Ask Devin が精度・コストパフォーマンスの両面で最も優れているという結論に至っています。Backlog のように長く育てられたコードベースの理解にも、この組み合わせは非常に役立っています。コードベースを文章として読むのではなく、対話で問いかけながら理解できる。新しいリポジトリに飛び込むときの心理的なハードルが、ここまで下がるとは想像していませんでした。「これがないともう無理だ」という声が、現場から自然と上がっています。

もう一つの Platform Engineering の発想は、推奨ツールの周りに、ガイドや学習機会という「舗装された道」を整える考え方です。「禁止」でも「野放し」でもなく、あえて他の道を選ぶ理由が見つからないくらい便利にする。強制ではなく、自然と歩みたくなる道です。それ以外の道も選べる、という前提を残しているのも重要です。

AI を単なるコード生成マシンではなく、頭の中の「ふわふわしたもの」を引き出して型にするための壁打ち相手・伴走者として使う。それが、AI ツールに私が期待することです。

この「ふわふわしたもの」を言葉にする行為は、オペレーショナルエクセレンスを目指すうえでの阻害要因、つまりメンバーが意識せずにやっている、名もなき取り組みにスポットライトを当てる行為でもあります。AI に仕事を任せようとするとき、人は自然と業務プロセスを言語化し、再利用可能な形に整理し始める。AI に任せるという行為そのものが、組織のオペレーショナルエクセレンスを目指す取り組みになる。これは、私たちが AI 活用の現場で得た発見の一つです。

実行: AIX Team、AIX Bootcamp、そして全社員に渡したもの

では、その処方をどう実行しているか。組織として駆動の中心にあるのが、AIX Team です。AIX Team は、ヌーラボの開発体験を AI ネイティブに進化させていく Center of Excellence (CoE) であり、各チームへの enablement や標準化を主な役割としています。

その思考法を実践的に磨く場として、AIX Bootcamp を立ち上げました。AI の使い方を覚えるのではなく、システム思考や仮説思考といった人間の思考力を、AI 時代に向けて磨き、鍛え直す場です。今後はモデルもハーネスも強くなっていきます。その中で変わらないのは人間の思考力だからです。ゲートやゴールの設定に寄与する思考法を磨いた方が、長期的にメリットが大きい。それが今の私の確信です。

配っているのはエンジニアにだけではありません。1 年前から、ヌーラボは Gemini を全社員に配布してきました。組織全体の知性として AI を活用するというスタンスは、当時から変わっていません。

ただ、これまでは Gemini 以外のモデルへのアクセスに課題が残っていました。エンジニアは、慣れ親しんだ GitHub Copilot のようなツールを通じて、Claude や GPT 系のモデルにも触れることができます。けれども、エンジニア以外のメンバーにとっては、別のモデルに触れる手段はそう簡単ではありません。組織全体のベースラインを上げるには、全職種が慣れ親しんだチャットインターフェースのまま、多モデルに触れられる状態を整える必要がある。そう考えて、今回 Claude Team の全社員配布を新たに加えました。Gemini と Claude ではハーネスの思想も異なります。それぞれの違いを踏まえた活用方法を、CoE として全社に伝えていく予定です。

一方で、AI ツールはこれまでシャドー IT と呼ばれてきたツールよりも、情報流出のリスクが潜在的に高く、シャドー AI は組織にとって大きな課題になりつつあります。これを避けるために、AIX Team が先んじてツールの導入戦略を立て、ライセンス・契約・セキュリティ・予算確保までを統括して進めています。もちろん、ユーザーリクエストを起点とした導入も並行して受け付けています。「禁止でも野放しでもない」ためには、こうした舞台裏の合意形成が欠かせません。

そして、私たちは AI を使う側であるだけでなく、お客様に届ける側でもあります。2025 年 6 月に Backlog AI アシスタントの提供を発表し、同年 7 月から β 版を順次提供、2026 年 3 月に 一般提供を開始しました。社内でコーディングエージェントや AI アシスタントを実際に使い倒し、評価し、運用してきた現場の試行錯誤。この積み重ねが、プロダクトに AI を実装する際の土台になっています。逆に、お客様に AI を届ける側に立つことで、社内活用の課題感もまた、顧客視点から捉え直せるようになります。

DORA の “State of AI-assisted Software Development 2025” は、こう述べています。“AI is an amplifier. Its impact depends on the quality of your platform” (AI は増幅器であり、その効果はプラットフォームの質に依存する)。同じテーゼは “The ROI of AI-assisted Software Development” の Executive Summary でも冒頭に置かれており、業界の見解として一貫しています。私たちはその言葉を、組織として真摯に受け止めています。

展望: この型を、もっと遠くへ

私たちが、この先に見据えているものを 3 つ挙げます。

ひとつは、思考力を磨く場の体系化です。AIX Bootcamp を、属人的な enablement から、再現可能な思考訓練プログラムへと進化させていきたい。新しく入ったメンバーも、同じ土台に乗れる状態を目指します。

ふたつ目は、「人間が AI 時代の思考法に進化する」という方向です。AI が人間に合わせる、ではなく、人間がゲート・ゴール設定の質で勝負する。モデルもハーネスも強くなる前提で、それでも価値を生み出せる人材像を磨いていきます。

三つ目は、自社プロダクト (Backlog / Cacoo / Nulab Pass) への AI 統合の深化です。Backlog AI アシスタントの提供開始は、その第一歩にすぎません。組織として磨いた経験を、これからもお客様の体験に還元し続けていきます。私たち自身がドッグフーディングする側であり続けることに、意味があると考えています。