テラスカイは6月3日、Salesforce環境に特化したAI駆動開発モデル「BLADE(ブレード)」を5月から開始したと発表した。同モデルは、AIを活用してビジネス目的・要件・テスト・実装のトレーサビリティを高度に担保することで、品質向上と手戻り根絶を目指す。なお、三菱電機における同モデルの先行事例も紹介された。
テラスカイのAI戦略と「BLADE」発表の背景
発表に先立ち、6月1日にメディア向けに説明会が開催された。昨今、AIの活用は効率化が中心になりつつあるが、同社は上流工程にフォーカスし「高品質なシステム開発の再現性」に軸を移した。
テラスカイ 代表取締役CEO 社長執行役員の佐藤秀哉氏は同社の立ち位置を「クラウドインテグレーターからAIインテグレーターへの転換期にある。クラウドインテグレーターのビジネスは、一区切りを迎えつつあり、今後はAIとどう向き合うかが問われる」と話す。
同社は2006年の創業以来、Salesforceを中心としたクラウド導入支援で成長してきたが、AIによって開発プロセスそのものが変化することで、従来のSIモデルが大きく揺らいでいるという認識を示す。
従来の開発は、設計・開発・テストといった工程に工数の大半が集中していたが、AIの導入によりそれらは自動化されつつあり、結果として価値の重心は「上流」と「下流」に移るという。
佐藤氏は「AIにより真ん中の開発工程は極端に軽くなる。そうすると、われわれがもう一度強くならなくてはいけないのは、上流としての戦略・コンサルティングと、下流である運用だ」と力を込める。
こうした前提のもとで同社ではAI時代に次世代モデルへの進化を牽引する3+1戦略に取り組んでいる。3+1戦略は「AI導入企業への変革」「AIレディ」「プラットフォーム企業への変革」、そしてAI駆動開発手法のBLADEというわけだ。
コード生成偏重に警鐘、Salesforce開発の課題とは
BLADEの説明に立った、テラスカイ 取締役 専務執行役員 クラウドインテグレーション統括本部 統括本部長の今岡純二氏は、現在のAI開発を巡るトレンドに対し、以下のような違和感を示す。
「多くの企業がAIにコードを書かせることに価値を見いだしているが、システム開発全体で見れば、コード生成は氷山の一角に過ぎない」(今岡氏)
同氏によると、要件定義や設計、テスト、運用といった工程が本質であり、そこを軽視したままコード生成だけを高度化しても、品質は担保されないという。特に、Salesforceのようなプラットフォームでは、その傾向が顕著になるとのこと。
Salesforceは、一般的なWebアプリケーションとは異なり、標準・カスタムオブジェクトが複雑に連携する密結合構造、フローやトリガーによる自動処理の連鎖、厳格なガバナ制限(リソース制約)などの特性を持つ。
こうした環境においてAIが単純にコード生成を行うと、問題が顕在化する。今岡氏は「AIは最も楽で早い方法を選ぶ。結果として、Salesforceのベストプラクティスを無視した実装を平気で生成してしまう」と指摘。
具体的には、標準オブジェクトを使わない設計(アーキテクチャ崩壊)、データ量増加で動かないコード(ガバナ違反)、管理不能な自動処理(ブラックボックス化)をはじめとした技術的負債が生まれる。佐藤氏も「AIは頭がいいが、同時に“ズルい"。一見動くものを最短で作るが、それがスケールするとは限らない」と述べている。
こうした背景を踏まえ、テラスカイが提示するのは、AIの役割そのものを再定義するアプローチだ。BLADEでは、AIを「コード生成エンジン」ではなく「設計支援エージェント」として位置付ける。
今岡氏は「重要なことは、AIにコードを書かせることではなく、AIをアーキテクトとして使うことだ」とし、その中核となるものが徹底した「テストファースト」と「上流設計の強化」となる。
BLADEの開発プロセス、テストファーストと上流設計
BLADEの開発プロセスは大きく2つに分かれる。設計・テスト定義(上流工程)と、AIによる実装(下流工程)であり、特徴的なのは要件定義段階からテストケースを作成する点だ。
従来は要件→機能定義→実装→テストであったが、BLADEは要件→目的定義→テストケース作成→設計→実装の順となる。同氏は「機能は目的ではなく手段。誰が何のために使うのかを定義し、その達成条件をテストとして先に決める」と説く。これにより、テスト段階での齟齬を減らし、手戻りの発生を抑制するという。
設計段階で合意された内容は、AIが理解しやすいマークダウン形式に変換される。ユーザーストーリーから受入条件、テストケースを含めた仕様をAIに入力することで、実装内容のブレを防ぐ。
今岡氏は「いわゆる“バイブコーディング”のような、その場のノリでの開発は排除する」と強調し、同プロセスにより理論上は手戻りゼロの開発を目指す。
従来の「作ったものをテストする」V字モデルから脱却し、要件定義の段階でユーザーストーリーに基づく受入条件(テストケース)を顧客と合意し、それをベースにAIが実装を行う「I型プロセス」を採用している。
トレーサビリティとプロンプトライブラリが生む差別化
また、BLADEでは要件から実装までを完全に紐付けるトレーサビリティを重視。要件、データ項目、設計、コード、テストのすべてが連動し、なぜその機能が存在するのかが追跡可能になる。「この項目は何のためにあるのかがわからない」という状態をなくすことで、変更時の影響分析や保守性も向上させる。
BLADEの競争力の源泉は、テラスカイが蓄積してきた知見にあり、20年分の設計ノウハウや障害対応の知見、Salesforce特有の制約理解だ。これらを体系化した「プロンプトライブラリ」としてAIに組み込んでいる。
佐藤氏は「われわれの強みは、知見を持っていることと、それをAIに正しく教え込めることだ」と、そのメリットを語っている。これにより、初心者でも高品質な設計やSalesforce最適化された実装、技術的負債の抑制を可能としている。
すでにBLADEは実案件での適用が始まっている。三菱電機では、2026年4月~9月の予定で国際輸送運賃入札システムの改修プロジェクトを計画。要件の精度向上、潜在ニーズの可視化、開発期間短縮などの成果を生み出しており、要件定義からテスト設計の完了までが従来の4カ月から2カ月に短縮。
エンジニア像の変化とBLADEの将来性
BLADEが示すもう1つの変化は、人材像のシフトだ。これまでは実装力が重視されてきたが、今後は設計力・言語化能力が重視されるという。同氏は「コードを書くこと自体には、もはや大きな価値は残らない。顧客のビジネスをどう定義するかが重要になる」と説く。
生成AIの進展により、ソフトウェア開発は転換点にある一方で、単純な効率化競争では、品質や持続性に課題が残る。BLADEは、そうした課題に対応するものとなる。
佐藤氏は「AIに仕事を奪われるのではなく、AIを使って自分たちのビジネスを壊す。その覚悟でやっている」と意気込みを語っており、BLADEが企業にどのようにフィットしていくのかが注目されるだろう。













