はじめに：コードが「書ける」ことの錯覚
AIがすっかり定着し、日常の相談からコーディングまであらゆることが可能になってきました。
Salesforce開発の現場も例に漏れず、AIの波が押し寄せてきています。
特にApexを使ったコーディングは今まで コードが書けない、読めないから触れてこなった人 がGemini や ChatGPT を使うことで簡単に class や Apex トリガーや テストクラス を生成できるため、一見開発効率は劇的に上がったように見えます。
しかし一方で、それによって 「コードが書けた」ことに満足してしまい、本質的な難しさを見逃していませんか？
動いたからOK？
カバレッジ通ったからOK？
いいえ、その先にこそ本当の課題があります。
見えない負債：コンテキストを跨いだ構造的リスク
Salesforceのように「設定とコードが共存する」環境では、1つの変更がどこにどう影響するかを読み解くのがとても難しいです。
たとえば、
- Flow（※プロセスビルダー含む）とApexトリガーの競合
- SOQLの多重発行とガバナ制限
- DML操作による再帰呼び出し
など、「構造の不整合」が簡単に起きます。
上記は全て私の実体験ですが、結局作った人は解消ができずそのまま退職、引き継いだ私がその構造を読み解き、一つ一つ直していったのです。
ノーコードやAIによる生成コードで 動くことで満足してしまうと構造的な負債が見えないまま蓄積されていくのです。
実例：ノーコード×AIで埋め込まれた負債たち
私が経験した具体例です。
⚠️ コード上で bulk insert をせず、1件ずつ insert → N+1発生
一見正しそうな insert 処理が、実はループ内で1件ずつ実行されていた。
その裏で after insert トリガーが走り、関連オブジェクトに SOQL を投げていたため、N+1クエリでガバナ制限を突破して処理全体が失敗。
AIが生成したコードは「動いた」けれど、設計の意図やガバナ制限への意識は一切なかった。
⚠️ AIが「テストを通すためだけのテストクラス」を書く
動作確認のためのカバレッジを稼ぐコードとして、本質的な動作検証を一切していないテストクラスが生成される。
最悪の場合、System.assert(true); のようなコードが大量に書かれていたり、副作用のあるテストデータを共通の TestDataFactory に書き込んで他のテストを壊すことも。
🧱 テストクラスはAI時代の“ガードレール”
それを人間が設置せずに、AIに肩代わりしてもらえば、
数ヶ月後には本来進むべき道から外れて崖から落ちているかもしれません。
余談
テストクラスでの値の検証には現在Assertクラスの使用が推奨されています。上のようにSystem.assertが使われている時点で最新の推奨された方法で実装されていないことが明らかです。
動くからいい、のではなくちゃんと推奨される方法で実装することでコードの健全性を保つ、これが大事なことです。
「動いた」だけで満足した先にあるのは、技術的債務
動作確認ができた。
テストが通った。
クライアントにデモができた。
その瞬間、安心してしまいがちですが、本当に重要なのはその先です。
- 生成されたコードは保守性が高い設計になっているか？
- テストクラスはビジネスロジックをちゃんとテストしているか？
- 数ヶ月後、別の機能が追加になる時に拡張しやすい設計か？
- 他者が見ても理解しやすい構造になっているか？
- 商談・見積など、組織の中心オブジェクトのデータフローに影響を与えていないか？
構造を横断的に読めていないコードは、動く時点では問題が見えない
だからこそ「見えない負債」が一番危ないのです。
エンジニアの価値は「読める」「見通せる」ことにある
AIはコードを 書くことは得意になりました。
でも、それを 読む こと、設計意図を見抜くこと、
将来の影響を見通すことは、まだまだエンジニアの仕事です。
特に Salesforce のような広く連携する仕組みにおいては、
- ログを読み解いて原因を特定し
- 他の処理との衝突を予見し
- 持続可能な構造に設計し直す
という力が求められます。
「AIにコードを書かせる」のは目的ではない
「将来まで壊れないようにコードを保ちつつ継続的な開発とデリバリを行う」のが、エンジニアの仕事です。
まとめ：AIとノーコードを“責任ある形で使う”ということ
ノーコードも、AIコーディングも、正しく使えば非常に強力なツールです。
私自身も日々使っていますし、今後ますます活用が広がるのは間違いありません。
ただし、AIの出力には責任を取ってくれないという前提を忘れてはなりません。
- AIを使ったコードが、全体構成を壊すかもしれない
- ノーコードで作ったフローが、将来的に破綻を招くかもしれない
- それに気づくのは、構造を“読める”エンジニアしかいない
だからこそ今後、真に価値を持つのは、
AIの成果物をレビューし、設計し、継続的に改善できるエンジニアです。
こんな兆候があれば要注意！
- ✅ AIが書いたコード、意味がわからないままデプロイしている
- ✅ テストが通っただけで安心している
- ✅ フローと Apex の間で処理の重複がある気がするが誰も調査していない
- ✅ ガバナ制限でたびたび処理が落ちるが、原因が特定できていない
- ✅ Salesforceのログを誰もまともに読んでいない（そもそも読めない）
これらがあるなら、見えない負債が静かに膨らんでいるかもしれません。
データベース依存のテストクラスからの脱却
継続的な開発のためにユニットテストを整備しますが、Salesforceが公式に進めるTestDataFactoryとSelectorパターンでは、Salesforce自身の制約上継続的な発展は不可能です。
ぜひ、ApexElquentを手に取っていただき新しい開発体験を感じてください！