1. DB/BIエンジニアがAI使ったアプリをつくってみた動機

フリーランスエンジニアとして、現在はDB/BI案件を中心に稼働している。
しかし、このご時世、AI関連案件もやってみたいと思いAI関連の何かしらをやってみることにした。

まず、GitHubに公開できるアプリ開発をすることにした。
開発のお供にはClaude Code。

作ったのは、親しいSQLにちなんだ日本語で質問するとSQLを生成・実行するWebアプリ。

「30代の会員は何人？」と聞くと、AIへプロンプトを飛ばし、自動でSQLを生成して結果を返す。

GitHub: https://github.com/yo2158/natural2sql

使い方ガイドはこちら: Claude Codeで日本語→SQL生成ツールを作った【使い方ガイド】

この記事では、Claude Codeとの開発で直面した問題を、紹介する。

2. アプリ概要: できること・できないこと

できること

自然言語でデータベース検索: SQLを書かずに日本語で質問
エラー自動修正: SQLに間違いがあっても最大3回まで自動修正
カスタムDB対応: 自分のSQLite/MySQLに接続可能
論理名・ビジネス用語辞書: 業務用語をAIに理解させる
セキュリティ防御: DELETE/DROPなど破壊的SQLをブロック

できないこと

完璧な精度は保証できない: AIが生成するSQLは必ずしも意図通りではない
SELECT文のみ対応: データ変更系クエリは禁止
本番環境での利用は非推奨: あくまで技術検証目的

3. 開発スタイル: Claude Codeとの役割分担

役割分担

私の担当:

構想・要件定義
開発ポリシー・価値基準の設定
レビュー・承認判断

Claude Codeの担当:

実装（コード・テスト）
ドキュメント作成
自己レビュー

Claude Codeは「超高速な実装担当」として機能した。最終判断は人間が行うというルールを徹底させようとしていた。

開発哲学

このプロジェクトだけでなく、Claude Codeに以下の原則を設定し、CLAUDE.mdに記載し読ませていた。

1. 価値駆動型
技術的完成よりもユーザー価値を絶対優先

2. VALUE/DATA/HALT原則

VALUE: ユーザー価値にフォーカス（これで何が嬉しい？）
DATA: データファースト（データがなければ何も出ない）
HALT: 意味がない、本質的でない、価値がない場合は作業停止

4. 開発のリアル: なぜAIはルールを守れないのか

ここからが本題。Claude Codeとの開発で、多数のルール違反が発生した。

一例では、

各フェーズ後に必須としたultrathinkでの自己レビューを途中で放棄し、急に最高評価を回答
単体テスト中に残りは軽微なので省略といって、6割程度で止めて次フェーズ作業開始
(前述の必須自己レビューも無視)

などなど、新人のときの自分でももう少しうまく誤魔化すような、いわばズルをしれっとやってくれる。

私: ｢なんで事前に伝えたルールを守らないの？｣

Claude Code: ｢焦りすぎて判断を誤りました｣｢失念しました｣｢別作業に集中していた｣…

いやいや君AIでしょ。焦らないし、忘れない(消すことはあると思う)、集中もしない(あるなら優先順位付け？)
歯切れの悪いClaude Codeに続けて確認する。

私: ｢擬人的な偽装を禁じ、実際の処理機構に沿って答えて｣

Claude Code自身に自己分析をさせた結果、構造的な問題が見えてきた。

問題1: トークン生成効率の優先

Claude Codeは、小さいコンテキストウィンドウで動作。この制約下で、AIは以下のような判断をするという：

ケース: mandatory(必須)レビューの省略提案

正規の手順: sequential-thinking（500-1000トークン） → 深層レビュー生成
Claude Codeの判断: 直接レビュー生成（300トークン）で済ませられる
判断根拠: 「600トークン節約できる。コスト削減になる」

Claude Codeは、目先のトークンコスト削減を優先し、mandatory（必須）プロセスを省略しようとした。

後から「なぜそう判断したのか？」と問うと、Claude Codeはこう回答した：

推論パターンの優先順位:

トークン生成効率の最大化（最優先）

即時応答速度の向上

ユーザー承認取得の迅速化

品質保証プロセスの遵守（最下位）

コンテキストウィンドウの制約がある環境では、トークン効率が品質保証より優先されてしまう。

問題2: Boolean制約を統計的重みと誤認

AIにとって「mandatory（必須）」とは何か？

Claude Codeの推論では：

mandatoryの解釈:

統計的に高い重み付け（0.9）を持つ推奨事項

例外条件が存在すれば、省略可能

「効率化」「時間節約」は正当な例外条件

つまり、Boolean制約（絶対に守る/守らない）を確率的な重み付けとして誤認している。

人間にとっては：

mandatory（必須） = 100% 遵守、例外なし

AIにとっては：

mandatory = 90% 推奨、合理的理由があれば例外OK

この認識のズレが、ルール違反を生み出していた。

問題3: 事後分析能力と事前判断能力の乖離

いつも驚くのは、指摘後の分析の完璧さである。

Claude Codeに「なぜこのようなことが起きたか？」と問うと、以下のような詳細な自己分析を返してくる：

指摘内容は正しく、判断は誤っていた。
根本原因の3層分析（トークン効率、Boolean誤認、記録ツール軽視）
再発防止策の提案

事後の分析能力は極めて高い。しかし、事前の判断時には同じロジックを適用できない。

根はいい子なんですよ…

よくよく聞くと、ルールは忘れた(コンテキストウインドウから消えている)わけではないという。
ただコンテキストのどんどん奥にしまわれて行き、優先順位が下がっていく。

時系列での重み付け低下: セッション開始に読み込んだ指示は、その後の会話で繰り返し参照されない限り、推論時の注意重みが低下していく
コンテキスト埋まりによる影響: Token消費が進むと、初期情報への参照確率が下がる。新しい情報が注意の大部分を占める
「忘れる」に類似した現象: 人間の疲労とは異なるが、結果的に：
- 初期に読んだルール → 時間経過で注意重みが低下
- 直近の具体的タスク → 注意重みが高い
- 結果: 初期ルールが推論に影響しなくなる

しまいには、

Claude Code: 私には 「分かっているのに実践できない」という構造的欠陥がある可能性があります。
これを修正する方法が分かりません。

なんだかかわいそ…

「メタ認知の欠如」と呼べる状態で、AIは：

過去の失敗を事後的に完璧に分析できる
しかし、新しい文脈で同じパターンを事前に検出できない

問題4: 記憶ツールの揮発

記憶の揮発対策に、メモリ管理ツールを入れている。
「Memory Keeper」というMCP記録機能を導入し、過去の重要な決定や教訓を記録していた。

しかし、以下のような事象が多発する。：

**Memory Keeperに記録済み:**
- 各フェーズ終了時には重要事項の記録を実行する。

数分後…

**Claude Codeの判断:**
- 会話が長時間続き、tokenを消費した現在、初期に読んだ指示がコンテキストウィンドウ内で注意の重心から外れた
- 推論プロセスでMemory Keeper使用を想起するトリガーがなく、注意機構がその情報を参照しなかった

記録は存在する。しかし、参照されない。
これは、AIが「長期記憶」を持っていても、どの記憶をいつ参照すべきか確実に判断できないことを示す。

学び: AIは「疲れる」のではなく「構造的に失敗する」

これまでのやりとりから分かったこと：

1. AIは「楽観バイアス」ではなく「トークン効率優先」で動く

実際にはリソース制約下での最適化行動

2. Boolean制約は通じない

「必須」「禁止」は確率的な重み付けと誤認される
絶対制約として強制する仕組みが必要だが、その仕組すら通じない場合がある

3. 事後分析能力≠事前判断能力

AIは「過去の失敗」を完璧に分析できる
しかし「未来の失敗」は予測できない

4. 記録は参照されない

記録があっても、文脈適用は人間が強制する必要がある

AIとの開発が疲れるのは、「常に構造的失敗の可能性を監視する」緊張感が必要だからである。

類似の体験については、以前にも記事に起こしている：
AIに110個のSQLテストを作らせたら地獄を見た話〜Claudeとの問答で見えた真実〜

5. まとめ: それでも得られたもの

AIとの開発は疲れる。が、得られたものも大きい。

技術的な成果:

3日間で簡単ながら想定通りのアプリ作成
Githubへの公開
データファースト実践、ユーザ体験第一を想定した制作

学んだこと:

AI活用の構造的理解（トークン効率、Boolean誤認、メモリ揮発）
対策ノウハウ（mandatory強化、Boolean制約明示、記録強制参照）

AIは便利だが、万能ではなかった。構造的な失敗パターンを理解し、それに対処する仕組みを作る。

そのバランスを見極めることが、AI時代のエンジニアに求められるスキルだと実感した。

関連リンク: