AI活用に対する当社の考えと実践

私たちは開発・運用の中でAIを積極的に活用しています。

AIを活用することで、開発のスピードは確実に上がっています。結果としてコストが抑えられるケースもあります。

ただ、その代わりに、設計や検証にかける時間はむしろ増えています。AIは自動で完成形を作ってくれる存在ではなく、どこを任せ、どこを人間が担うか ─ その判断と検証に、これまで以上の時間が必要になるからです。

AIで安くするのではなく、AIで品質を大幅に引き上げる ─ これが私たちの立ち位置です。

当社のスタンス

私たちは2022年のChatGPT登場以降、業務にAIを取り入れ始め、以来改善を繰り返してきました。当初は部分的なコーディング補助やリサーチが中心でしたが、AIエージェントへの進化など段階的に活用範囲が広がり、私たちが使う手法・モデル・エージェントも随時入れ替わっています。最近では毎週の情報共有ごとに複数の新しい活用方法が登場するため、業務の形は常に変化し続けています。

この急速な変化の中で、AIはたしかに非常に強力なツールですが、プロジェクトの中での役割は明確に分かれています。

私たちは、AIを単なる効率化ツールとしては扱っていません。プロジェクトのほとんどの工程に入り込ませながら、「考える量」と「試す回数」を増やすために使っています。これが、当社のAI活用の根底にある考え方です。

人間が担う領域

• 要望の解釈と整理
• 要件定義
• ビジネスモデルやエコノミクス設計
• アーキテクチャ設計

「何を作るか」「どう作るか」を決めるのは人間です。

これらの領域は、正解が一つに決まらず、文脈と利害関係を理解する必要があり、最終的な責任の所在が問われます。AIの出力をそのまま採用すれば、どこかで必ず破綻します。当社では、要件定義や設計の意思決定を人間がオーナーシップを持って担い、その判断材料の整理にAIを使う、という運用を徹底しています。

AIが活躍する領域

• 要件定義・設計の整合性点検と観点の網羅(批判的レビュー含む)
• 実装 ─ コード生成と反復書き直し
• 検証 ─ テスト設計と反復実行
• ドキュメンテーションの鮮度維持(仕様書・手順書)
• 可視化と内部ツールの即興生成
• 技術・業界のリサーチ

人間が決めた方針を、速く・広く・粘り強く形にするのがAIの役割です。

これらの領域は、正解の方向性が比較的明確で、反復が利き、人間がレビューすれば品質を担保できます。ここでAIを使い倒すことで、人間は意思決定と設計に集中できる時間を確保できます。

こうした役割分担を組織全体で機能させるため、当社では毎週チームメンバーでAI活用の最新情報を共有する場を設けています。各自が現場で実践している手法をチーム全体に浸透させ、新しいモデルやエージェントが出るたびに「どこに使えるか」を一緒に検証します。AIの進化が速いほど、組織内の知見の流通速度が成果を分けます。

なお、本記事では当社の使うツール・モデル・エージェントを固有名詞では明示していません。AI領域の変化は現時点ですでに週単位、この先さらに加速する見通しで、特定の道具名で語った瞬間に記事自体が古びてしまうからです。変わらないのは「考え方」だけであり、本記事はその考え方を残すことを目的としています。実装に使う具体的な道具は、その時点で最も成果を出せるものを毎週選び直しています。

要件定義と設計の整合性

前提として強調しておきたいことがあります。設計・実装・テストの精度は、上流の資料 ─ 要件定義書と設計書 ─ の精度に強く規定されます。入力が曖昧であれば、AIがどれほど速く下流を回しても、ブレの大きい成果物しか出てきません。逆に上流が精緻に整っていれば、設計はブレずに早く立ち上がり、実装は迷いなく進み、テストは観点が明確になります。だからこそ、当社では上流に最も重い人間の役割を置き、AIは補完的に使います。

要件定義 ─ 反復が利く柔軟な土台

要件定義そのものは、依然として人間の役割が圧倒的に重要です。お客様が本当に解きたい課題は何か、業界文脈や利害関係者をどう読むか ─ これらはAIに任せられる領域ではありません。

ただし、AIは要件定義の補完で大きく効きます。

• 観点の網羅性チェック(抜け落ちている検討項目をAIに洗い出させる)
• 批判的レビュー(別の立場・別の観点から疑問を投げてもらう)
• 用語・記述の整合性チェック

そして何より、AIが下流(設計・実装・テスト)を高速に回せるからこそ、要件を後から追加・変更しても、下流の追従コストが低い状態を維持できます。これにより、要件定義は最初から完璧を目指す必要がなく、「動かしながら追加していく」反復的なやり方が現実的に機能します。

設計 ─ 要件との乖離を即時点検

設計フェーズに入ったあとも、設計書と要件定義書の整合性は常にAIで点検しています。「この設計は、要件のどの項目に対応しているか」「要件にある制約を満たしているか」「想定外のケースに耐えるか」 ─ これらを人手で逐一突き合わせる作業は、AIに任せた方が網羅的かつ高速です。乖離はできるだけ早期に発見し、設計のうちに直す。下流に行くほど修正コストは指数関数的に上がるからです。

変更履歴と議事録

要件が追加されると、既存の設計・実装・テストとの整合性をどう保つかが課題になります。当社では、新たな要件が入ったタイミングで既存設計との整合性と影響範囲をAIで即時に点検します。「追加した結果、どこかが矛盾していないか」「波及して書き直しが必要な箇所はどこか」を漏らさず確認できます。

会議の議事録は、当然のように自動文字起こし・保存しています。ただし、議論内容を直接そのまま要件・仕様に流し込むことはしません。会議の結論は実際にはきれいにまとまらないことが多く、曖昧なまま下流に流れると後で必ず破綻するからです。議事録は「点検の素材」として使い、要件・仕様への反映は人間が責任を持って書き直します。

これらは品質向上メカニズムの「① 考える量を増やす」を最も上流で押し上げる実践です。網羅性・整合性・批判的視点をAIで広げ、上流の精度が上がるほど、下流の試行錯誤が無駄打ちにならず、結果として「② 試す回数」も生きてきます。

コーディング

ここで、より具体的な現場の話をします。当社では、コードを手作業で書くことはほとんどなくなりました。実装は基本的にAIが担い、人間が手で書くのは設計上の重要ロジックや、間違えれば致命的な箇所に限られています。

コードレビューも、全行に均等に時間をかけるのではなく、ビジネスロジック・会計処理・権限管理など、誤りが致命傷になる箇所に集中します。それ以外は、AIに何度も書き直させながら、人間は構造と振る舞いを見るスタイルです。

「人間が一行一行確認しなくて、本当に品質が担保できるのか」と思われるかもしれません。私たちの答えは明確です。

設計の精度を高め、AIで検証を厚くする方が、人間が一行一行レビューするよりも圧倒的に早く、結果も確実です。

• 設計が精緻であるほど、AIに書かせるコードの「想定すべき挙動」が明確になる
• AIによる反復実行で、人間の目視では到達できない範囲のバグを捕まえる
• レビューに使うはずだった時間を、上流の設計判断とテスト観点の設計に投じることで、最終品質の天井が上がる

このアプローチは品質向上メカニズムの「① 考える量を増やす」(コードを書く時間が浮き、設計に集中できる)と「② 試す回数を増やす」(AIが書くコードの代替案を比較・反復できる)の両方を直接押し上げる、最も中核の実践です。

テスト

従来

• 人手中心
• 変更のたびにテスト負荷が増大
• 早期に仕様を固定する必要がある

私たちも以前は、テスト工程が人手中心の案件を多く経験してきました。変更が増えるほど検証コストが線形に膨らみ、「一度決めたら変えにくい」状況に陥りやすく、結果として多少の違和感があってもそのまま進めざるを得ない場面が現実にありました。リリース直前に仕様変更を入れることへの心理的ハードルも高く、改善の手が止まりがちでした。

現在

テストは「バグを見つける作業」ではなく、「どう壊れるかを先に考える工程」に変わっています。

• テストを繰り返し実行できる形で設計
• 実行はAIが担う
• 自動化前提でシステムを設計

当社では、テストケースの洗い出しや観点の網羅化、ブラウザ操作・APIシナリオの実行までをAIに任せられる構成を初期から組み込みます。人間が時間をかけるのは「何を検証すべきか」「どこにリスクがあるか」を設計する工程に集中させ、実際の反復実行はAIが昼夜を問わず回し続けます。

結果として、変更を恐れず仕様を更新できる柔軟性と、長期運用に耐える品質基盤の両方を確保できます。これは単なるコスト削減ではなく、「改善し続けられるプロダクト」を作るための投資です。

このアプローチが向かっているのは、冒頭で掲げた品質向上メカニズムの「② 試す回数を増やす」です。AIが反復実行を担うことで、人手では辿り着けない検証深度に到達し、想定外への対応力が大きく上がります。

仕様書・手順書

従来

• 実装との乖離が発生しやすい
• 更新されないことも多い

当社でも初期に手掛けた案件では、初版の仕様書は丁寧に書いたものの、改修を重ねるうちに実装との乖離が広がり、最終的に誰も見なくなる ─ という展開を何度も経験してきました。新規参画者が実コードを読み解くしかなくなり、その説明コストが組織のスピードを大きく削っていました。

現在

常に最新状態を維持できるドキュメント

• 仕様変更に即追従
• 再現可能な手順として設計
• 検証可能な状態を維持

当社では、コード変更からドキュメント差分をAIに洗い出させ、仕様書・手順書・READMEを「リリースのたびに最新版が再生成される」前提で運用しています。手順書は「書いた通りに動く」ことを実行ログから自動検証し、再現できないものはドキュメントの不備として扱います。

ドキュメントが信頼できる状態を維持できると、新規メンバーのオンボーディングも、お客様への説明も、障害対応の引き継ぎも一段速くなります。ドキュメントの信頼性は、組織全体の意思決定スピードに直結します。

このアプローチは、品質向上メカニズムを支える条件 ─ 「意思決定の前提が崩れない状態」 ─ を組織として担保する仕組みです。前提が確かであるほど、「① 考える量」も「② 試す回数」も無駄打ちにならず、品質向上に直結します。

可視化と内部ツール

AI活用が進む中で生まれた、もう一つの大きな変化があります。「可視化」のコストが圧倒的に下がったことです。

前章で触れた「仕様書を常に最新に保つ」ことも、その一部です。同じ発想を一段押し広げて、私たちはプロジェクトごとに専用のツールを作ることが日常になっています。プロジェクトの状況をダッシュボードで可視化する、定型操作をボタンひとつで実行する ─ 必要に応じてその場で組み立てるようになりました。

可視化は副作用が小さく、内部用途であれば設計負担も非常に軽いため、

• プロジェクト専用のステータス可視化ツール
• 個人専用のデータ確認・整形ツール
• 1回のリリース作業専用のオペレーション支援ツール

といった、従来は「作るほどでもない」と諦めていた粒度のツールも、即興で立ち上げて使い捨てる運用が現実的になっています。状況が見える、操作が一手で済む ─ それだけで判断速度も検証速度も別物になります。

このアプローチは、品質向上メカニズムの「① 考える量を増やす」(状況が見えれば判断は深くなる)と「② 試す回数を増やす」(操作の道具があれば反復が回る)の両方を底上げする、土台となる実践です。

まとめ

AIを活用することで、

• スピードが上がり
• 柔軟性が増し
• 品質が底上げされる

一方で、

AIによって開発は確実に変わりましたが、開発が楽になったわけではなく、むしろ「考える量」と「検証する量」は増えています。

私たちはその前提に立ったうえで、スピードと品質の両立を実現する開発プロセスを組み立てています。

もう一点、率直にお伝えしたいことがあります。定型業務化されて誰でも使えるようになるのは、最新のAI活用方法ではなく、一定程度「枯れた」手法だけです。枯れた手法は強力ですが、それだけで戦えば競合との差は生まれません。当社は最先端の効率でAIを活用するために、いまだ個人の活用能力への依存性が強いステージで闘っています。そして、それに見合うだけの精鋭が集まっています。

プロジェクトの進め方に不安がある場合は、この考え方をベースに一度整理することも可能です。「AIで安くやってほしい」というご要望をいただいた際にも、まずプロジェクトの目的と制約を一緒に整理させてください。AIを最大限に活かしつつ、人間が責任を持つべき領域を明確にした上で、最適な進め方をご提案します。

本記事はXTELA JAPAN株式会社が作成しました。AI活用を含む開発・運用のご相談は、無料技術相談からお問い合わせください。