AI Tool

💡【ログ解説】AIオーケストレーションで文脈崩壊を起こす「コンテキスト窓」の限界と、エージェント設計の鉄則

あるエンジニアがAI（Copilot）との10日間にわたる対話を通して、「AIが設計方式を理解し保持している」という前提の危うさを痛感。翻訳プロンプトの欠陥、辞書衝突、方式仕様書固定化の提案、そして「あなたの作業は1行だけ」という非現実的な要求に失望。AIは記憶を持たず、一貫性を担保できないことを実証。プロジェクト管理のプロが導き出した「AIは補助ツールに過ぎない」という冷静な結論。生々しい対話記録をもとに、AI開発の現実を鋭く描く。

2026.06.25 2026.06.26

AI Orchestration

💡 Gemini/Copilotが「スピナーなしでフリーズ」する原因と、APIのタイムアウト・ハルシネーション例外処理の防衛策

AI（GeminiやCopilot）との長大なやり取りで発生する「完全無反応・フリーズ」の恐怖。ローディングスピナーすら消えるWebブラウザの限界（DOM/メモリクラッシュ）の技術的背景と、AIの迷走や暴走を資産に変える、Wordを活用した超実践的な「自前LOGシステム」と新スレッド復旧の極意を解説します。

2026.06.20 2026.06.21

AI共生

【Pythonの罠】20万行のXML解析でエラーを出さずに「0件虚無」になるElementTreeの名前空間（Namespace）のバグと対策

WordPressのXMLエクスポートから特定記事を抽出しようとした開発者が、PythonのElementTree（xml.etree.ElementTree）の最悪の「サイレントスルー仕様」に嵌まり、13時過ぎまで激闘したノンフィクション記録。エラーを出さずに0件を返す名前空間の罠と、それを力技の正規表現（re）で踏み潰した生存戦略を解説。

2026.06.18 2026.06.21

AI Orchestration検証シリーズ：向き合い方

【AIオーケストレーションの嘘】根拠ゼロの「20/10/10ルール」を繰り返すCopilotと、有効英文比率38%の残酷な現実

Tune OCRの636行を前に、Copilotと共に「20/10/10方式」でノイズ除去を試みたが、行単位判定の限界と後出し前提により完全破綻。8日間の迷走の末、「全文連結＋英文法＋辞書照合」という新方式へ転換。AIオーケストレーションの「闇（誤診・デグレード・ハルシネーション）」と「光（人間の方式設計＋AIの忠実な実装）」を、実際の対話ログを交えて描く。スマートな進捗ではない、泥臭いAI共生の核心。

2026.06.14 2026.06.26

AI Orchestration

【実録21日間の泥沼】DeepSeekの無限ループ、Qwen2.5の0件正常終了。AIの粗暴なリラン提案を却下し続けたデータ前処理闘争記

AI オーケストレーションの続編。PDF マニュアルの文字化け、Copilot の迷走、Qwen2.5 の沈黙、Python の罠──再々設計と２重遭難を乗り越えた技術的記録。AIオーケストレーションの限界と最適解から続くエンタープライズ級Pythonバッチ設計

2026.06.10 2026.06.14

AI Orchestration

【DeepSeek暴走対策】AIオーケストレーションの限界を超える、ガードレールを取り入れたエンタープライズ級Pythonバッチ設計

AIに丸投げでは出来高50%未満の赤点？AS/400のCLP構造や150語のルールでDeepSeekが暴走した実体験から、Copilotとの役割分担、Claude 4.5 Sonnetの有効性、PCローカル環境（Ryzen AI 9）で品質100%を叩き出すPythonパイプラインの最終設計図までを徹底解説。Ryzen AI 9 HX470 LLM

2026.05.23 2026.06.26

AI OrchestrationAI共生

【フルライフサイクル実録】Gemini/Copilotと挑んだ21日間：要求定義からPythonバッチ運用までAIと協働する「開発プロセスの現実」

Geminiの暴走と迷走に苦しんだ開発者が、Copilotと共に「要求設計→外部設計→内部設計→プログラミング→バッチ運用」まで AI と協働し、PDF英文マニュアルの翻訳バッチを完成させるまでの21日間を記録。AIと安全に共生するための最重要ポイントを技術者視点で解説。Ryzen AI 9 HX470

2026.05.16 2026.05.17

AI共生

【ローカルLLM】GUIからCLI（Ubuntu）へ移行して、PDF自動翻訳バッチを完全自動化・安定運用する設計手法

GUI中心のLM Studioから、Ubuntu上のCLI運用へローカルLLMをシフトし、PDF自動翻訳バッチをどのように設計するかを整理。ocrmypdfとllama-cli、DeepSeek-R1やGemma4を用いながら、IBM i 的な運用思想でAIを「使う」から「共に動かす」へ移行する道筋を解説。Ryzen AI 9 HX470

2026.04.17 2026.05.16

AI共生

【ローカルLLMの限界】モデル選定とマニュアル翻訳の実践から見えた「コンテキスト解像度」の壁と対策

生成AIは便利だが、時に平然と“嘘”をつく。だからこそ私はクラウド依存を避けるために Local LLM を導入し自分の手元でモデルを動かすことに挑戦した。しかしPDFのページ数が増えた瞬間に精度が落ち前の文書の内容が混ざりモデルを eject して再読み込みするという作業を繰り返すことになった。この章では私が実際に行ったモデル選定PDF解析の試行錯誤そして「Local LLM の限界」をどう乗り越えたかをまとめる。Ryzen AI 9 HX470

2026.04.08

AI共生

【ハルシネーション対策】生成AIの「嘘」を制御する：マニュアル翻訳バッチにLocal LLMを導入した理由と設計

生成AIを利用する際に最も重要なのは、AIを誘導しないことである。ユーザーが意識していないと、AIは欠損した情報を補完し、もっともらしい文章を生成する。以前の記事でも触れたように、存在しない製品の型番や仕様を提示するケースが確認されている。これは特定のモデルに限らず、生成AI全般に共通する構造的な特性である。本稿では、LM Studio を用いて複数の Local LLM を検証した結果をもとに、生成AIの特性と、AIとの共生に必要な視点を整理する。Ryzen AI 9 HX470

2026.04.04 2026.04.05

AI共生