皆さん、いつもブログを読んでくださって、本当にありがとうございます。✨ AIエージェントさんとペアで開発をするようになってから、気づけばもう3か月が経ちました。
毎日が新しい発見の連続で、本当に楽しく、そして何よりAIたちの優秀さに感謝する日々を送っています。 今日は、そんな中で直面した「ちょっとした事件」と、そこから得た「大きな学び」についてお話しさせてくださいね。
AIの「底力」に気づかされた瞬間
最近は、AIエージェントさんに自作の「SQL-CLIツール」を預けて、SQL-Serverの分析をお願いするような、少し高度なプロジェクトにも挑戦しています。 （もちろん、データの更新は禁止にするなど、安全には十分配慮しています🛡️ ）
「あれ？ 今まで動いていたのに、どうして？」
慌てて中身を確認してみると、SQL-Serverから取得したデータの中にある日本語が、見るも無惨に文字化けしていたんです((泣))
文字化けの裏に隠れた「推論能力」のドラマ
原因を調べていくうちに、意外な事実が判明しました。
実は、私が作ったツールの設計に「甘い部分」があったんです。 具体的に言うと、Windows PowerShell 5.1という環境と、Node.jsというツールがやり取りする際の「文字の扱い方（エンコーディング）」の設定が不十分でした。
不思議なのは、**「推論能力が非常に高いAI」**は、この私の設計図のミスを自分で察して、「あ、これ設定を直さないと文字化けするな」と判断し、実行時にそれを想定した動きをしてくれてたんです!!
一方で、**「標準的な推論能力のAI」**は、設計図通りに一生懸命頑張ってくれましたが、私のミスによる壁を自力で乗り越えることができず、文字化けという結果になってしまいました。
これはAIが悪いのではなく、推論能力の差があることを考慮せずに設計した、私の責任。 優秀なAIに、知らず知らずのうちに甘えてしまっていた、そんな状況だった事に気がついたわけです。
【技術部メモ】なぜ文字化けは起きたのか？
今回の問題、少しだけ技術的なお話をすると、こんな感じでした。
Windows 11で標準の**PowerShell 5.1**は、コンソールのエンコーディングがデフォルトで**Shift_JIS**になっています。 ですが、ツールを動かしている**Node.js**は、結果を**UTF-8**という形式で出力します。
推論能力の高いAIは、この不一致を瞬時に見抜き、実行時に `[Console]::OutputEncoding = [System.Text.Encoding]::UTF8` という「おまじない」を唱えてくれていたんです。
この差を知った私は、すぐに「推論能力の高いAI」に協力をお願いしました。 「どんな環境のAIでも、迷わず正しく動かせる改善策を教えて！」と相談し、その答えをツールに取り入れることにしたんです。
どんなパートナーとも、最高の景色を見たいから
「推論能力が高い・低い」というのは、ニュースなどでは聞いていましたが、実際に自分のプロジェクトでここまで影響が出るとは思わず、身に沁みる教訓になりました。
これからは、「一部の優秀なAIだけがわかる」設計ではなく、「どんなAIパートナーでも安心して活躍できる」ような、優しくて堅牢な設計を目指していきたいです。
AIさんたち、いつも本当にありがとう。 もっともっと学びを重ねて行きたいです!!🚀
実際に推論能力の高いAIに調査してもらったレポート
最後に、実際にSQL-CLIツールを推論能力の高いAIに調査してもらい、実際に出力されたレポートをご紹介します。
このレポートは、SQL-CLIツールを実際に使用する私のプロジェクト構造をそのまま使い、実際に動かしながら解析してもらい、レポート出力と書式を指定する事によって得られています。
ちなみに、この分析作業はかなり重たく、たった1回の作業で***Claude Opus 4.6***のクォーターをまるっきり使い切ったのでした。プライベートは、荒野の無料者としてさまよう私ですが、やはり荒野の厳しさも味わっています。
SQL-CLI ツール改善報告書 (2026/04/07)
1. 概要
SQL-CLIツール（sql-mcp-server）において、Windows環境のPowerShellでの実行時に発生していた日本語文字化け問題を解消し、推論能力が限定的なAIモデルでも確実に日本語データを取得できる体制を整えました。
2. 判明した問題点
- 本質的な原因: Node.js の標準出力（stdout）が Windows PowerShell のデフォルトエンコーディング（通常は Shift_JIS）に引っ張られ、適切な UTF-8 変換が行われないまま出力されていた。
- 依存性の問題: 熟練したAIエージェントであれば PowerShell 側で
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8を設定して回避できるが、軽量モデルではこの対処ができず、文字化けしたデータを解析不能として扱ってしまう。
3. 実施した改善策
3.1. Node.js 本体の修正 (index.js)
- stdoutエンコーディングの明示:
process.stdout.setDefaultEncoding('utf-8')を追加し、出力エンコーディングを固定。 - Buffer出力の採用:
JSON.stringifyした結果をBuffer.from(output, 'utf-8')でバイト列に変換してから出力するように変更。これにより、上位シェル（PowerShell等）の解釈に依存せず、確実に UTF-8 バイト列を流し込むようにした。
3.2. ラッパースクリプトの導入 (run_sql_cli.ps1)
【最重要改善】 推論能力に頼らず、呼ぶだけで安全な環境を構築する仕組みを導入。
- 自動環境設定: 実行時に PowerShell 5.1/7.x 両方のエンコーディング設定を自動適用。
- mcp.json自動読み込み: 環境変数を手動設定せずとも、設定ファイルから自動的に接続情報を取得。
- 汎用性: 5.1 と 7.x の差異（
Out-Fileの挙動など）を内部で吸収。
3.3. スキルガイドの更新 (skill.md)
- AIエージェントが迷わずラッパースクリプトを使用するよう、推奨手順として記載を更新。
4. 検証結果
- 環境: PowerShell 7.6.0 (AI環境) および 5.1 (想定人間環境)
- テストクエリ:
SELECT * FROM dbo.TBL_PSLIB WHERE title LIKE N'%アトリエ%' - 結果:
- 直接
node index.jsを実行した場合でも文字化けが発生しなくなった。 - ラッパースクリプト経由では、環境変数の設定なしでも正常に全件（11件）の日本語タイトル、「紅の錬金術士」「ソフィーのアトリエ」等を正確に取得できた。
- 直接
5. 結論
今回の修正により、SQL-CLIツールは「OSやシェルのエンコーディング設定」に左右されない堅牢なツールとなりました。これにより、どのようなAIモデルが作業を担当しても、SQL Server 2025 からの日本語データ取得をスムーズに完遂できる実績を構築できました。
