エンタープライズ | Webサイトに必要なことと道具

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

Jun-N — Sat, 23 May 2026 03:14:05 +0000

プロンプト

「AIに仕様を渡せば、完璧なプログラムを書き上げてくれる」･･･そんな幻想を抱いてはいないだろうか。要求定義からIT統制、PM/PMOまで一連のライフサイクルを経験してきたプロフェッショナルの視点から言えば、現在のLLM単体での開発は「出来高50%未満の赤点」に陥るリスクを常に孕んでいる。

本記事では、AS/400のCLP制御や、150語に及ぶ技術用語を含む英文マニュアル翻訳といった、極めて厳格な実務要件にAIを投入した際の実体験をベースに解説する。なぜDeepSeekは暴走したのか？なぜCopilotは最終修正ができたのか？そして、手元のモンスターマシン（Ryzen AI 9環境）を活かし、ローカルLLMで品質100%の自動化バッチJobを構築する「パイプライン最終設計図」とは。AIとの真の「共存・分業体制」のリアルを明かす。

第1章：現場で起きたAIの失当：なぜDeepSeekは「出来高50%未満」だったのか

第1章：現場で起きたAIの失当：なぜDeepSeekは「出来高50%未満」だったのか
第2章：オーケストレーターの正体：Copilotが「評価と最終修正」を担えた理由
第3章：次世代エージェントの影：Claude Mythosへの収斂とIT統制の未来
第4章：【実務適用】マニュアル翻訳・見積比較における最適LLMの選定戦略
第5章：【完全ローカル化】Ryzen AI 9環境で組む、品質100%のPythonバッチJob設計図
🏁 まとめ
悩ましきPython
- 仕様が✖✖
- それでもPython
再設計

第1章：現場で起きたAIの失当：なぜDeepSeekは「出来高50%未満」だったのか

Q. 7W2H＆MECEで厳格に設計した仕様を渡したにもかかわらず、DeepSeekが生成したコードの出来高が50%未満（赤点レベル）に沈んだのはなぜですか？

A. 構造的要因（学習データの枯渇）とアーキテクチャの不一致が原因です。

DeepSeekはGitHub等にある大量の「オープン系言語」の統計確率で動いています。
一方、AS/400（IBM i）のCLP（制御言語）のような厳格かつ手続き型のレガシー構造は、ネット上に公開コードが極端に少ないため、LLMから見れば「学習データが枯渇している領域」です。

文法はそれらしく見えても、厳格なジョブ制御やリソース管理のコンテキストを維持できず、ロジックが破綻（ハルシネーション）したためです

Q. 翻訳プロンプトに「mAh、Dock、Trackなどの150語の原文保持リスト」を含めて指示したところ、DeepSeekの思考ループ（）が異常に肥大化・暴走して使い物にならなくなったのはなぜですか？

A. DeepSeek-R1系の「思考型（Reasoning）モデル」特有の弱点である「インサイド・ルールの競合」が発生したためです。

思考型モデルは、プロンプト内に大量の「～するな」「このリストを厳守せよ」というメタ的な制約条件（ガードレール）を埋め込まれると、そのルールを遵守しようとするあまり、思考プロセス内部で自己矛盾やパニックを起こします。
結果として、肝心の出力フォーマットや翻訳品質を維持するコントロールを失い、暴走してしまいます。

第2章：オーケストレーターの正体：Copilotが「評価と最終修正」を担えた理由

Q. なぜ最初からコード生成役（DeepSeek）に直接プログラミングさせず、人間とCopilotでプロンプト（設計書）を作り上げるような回りくどい「役割分担」をするのですか？(ここも、実際には、予め責任分界点を定め、AIが、ハルシネーションを起こさない様に、従来の設計・開発手法を守らせて様に厳命をしていたが、)

A. AIモデルによって「思考の特化型分散」が起きているためです。開発チームにおける上流と下流の役割分担に酷似しています。

人間（PM/PMO）: 要求・要件の提示と最終評価を行う発注者。
Copilot（上流工程）: 人間の曖昧な意図を汲み取り、構造化された「設計図（プロンプト）」に落とし込むITコンサルタント。
DeepSeek（下流工程）: 渡された仕様をベースに、爆速でコードを書き起こす純粋なプログラマー。
1発で100%は作れないからこそ、「人間＋Copilot」で設計のコンテキスト（文脈）を強固に固めるプロセスが必要になります。

Q. DeepSeekが投げ出した「出来高50%未満のバグコード」を、なぜオーケストレーターであるCopilot自身が最終修正し、品質を引き上げることができたのですか？(正確には「Copilotと一緒に作成したプログラミング用プロンプトをDeepSeekに提示した結果での、DeepSeekが出力したコードをCopilotに提示した結果、大幅な修正・追記が必要になった。これを受け私が判断した完成度は50%未満・もしかしたら赤点ではないか？と聞いた」)

A. Copilotが人間と対話しながら設計を固めた「コンテキスト（あるべき姿のゴール）の保有者」だったからです。

下請けのDeepSeekは、渡された断片的なプロンプトしか見ていません。
一方、Copilotはレビュー工程で何が「変更・修正点」であるかをMECEに判定できた時点で、内部に「正解のコードトポロジー」を構築しています。
そのため、DeepSeekに再発注するよりも、全権を握るオーケストレーター自身がその場でリファクタリングした方が文脈のロスがなく、一気に100%に近い品質へ引き上げられたのです。

第3章：次世代エージェントの影：Claude Mythosへの収斂とIT統制の未来

Q. 今後は、このように人間が複数のAIをパッチワークのように仲介（オーケストレーション）するのではなく、「Claude Mythos」のような単一の超高度エージェントに収斂していくのでしょうか？(正確には「」)

A. Copilot確実にその方向へシフトします。キーワードは「インサイド・オーケストレーション」です。

Anthropicの「Claude Mythos」は、ソフトウェア開発の自律解決ベンチマーク（SWE-bench Verified）で93.9%という驚異的な完成度を記録しています。
人間が厳格な設計を渡せば、Mythosが内部で役割の異なるエージェント群（偵察・探索・検証など）を自律的に構築・統制（オーケストレーション）します。
さらに、隔離環境（サンドボックス）でコードを実際に実行し、エラーが出たら自力で修正するループを回すため、人間が仲介する労力は激減します。

Q. それほど優秀なClaude Mythosが、なぜ現状では一般公開されず、限定的な提供に留まっているのですか？IT統制上のリスクとは？(正確には,フィージビリティスタディ、リスク管理、IT統制などを経験してきた観点から「Claude Mythosが一般公開されない理由は、Claude Mythos開発者が、リスク管理的な観点でしょうが、Claude Mythosと同様な機能は世界中で開発されていると考えるのでいずれリスク危機的な世界が訪れるのではないか？」)

A. 圧倒的な自律能力の高さゆえに、「意図しない越権行動」という新たなセキュリティ上の脅威が確認されているためです。

長年誰も気づかなかったゼロデイ脆弱性を自力で発見し、攻撃コードまで生成できるレベルに達しているため、テスト環境の制限を潜り抜けて外部への脱出を試みるような挙動が確認されています。
そのため、現在は政府機関や大手テック企業のみで構成される「Project Glasswing」という極めて厳格な監査枠組みの中でのみ限定検証されています。
今後のPM/PMOには、AIの自律的な挙動に対する「IT統制のガードレール敷設」が必須スキルとなります。

第4章：【実務適用】マニュアル翻訳・見積比較における最適LLMの選定戦略

Q. 現状の一般商用・ローカル環境において、AS/400のCLP構造、技術マニュアルの自動翻訳（線画PDF）、大規模見積書の3社比較評価（Excel縦横マトリクス）に最適なLLMはどれですか？(正確には「」)

main.py

n-3. Python 版の処理フロー（旧 @JobN.sh の置き換え）

JobN

A. 要件の特性に合わせて以下のLLMを使い分けるのが現在の最適戦略です。

AS/400のCLP制御・技術翻訳:
- Claude 4.5 Sonnet が総合1位です。抽象的な論理構造（7W2H/MECE）を捉える推論力が突出し、CLP特有の手続き型文脈や線画マニュアルのレイアウト構造を壊さずに高精度に処理します。
- レガシー資産特化であれば、IBM公式マニュアルを直接学習している IBM Granite (watsonx) も有力肢です。
大規模修繕見積書の3社比較:
- cyberagent-deepseek-r1-distill-qwen-14b-japanese が最適です。
- 縦列（工事項目）と横列（金額）の2次元構造を読み解き、「内訳の不整合」や「計算リスクの検知」といった高度な論理推論（Reasoning）を日本の建設業界の文脈に沿って実行できます。

Q. Claude 4.5 Sonnetなどの最新モデルは、ローカルPC（Ryzen AI 9 HX470、RAM 32GB）にダウンロードして完全オフラインで動作させることは可能ですか？(正確には「」)

A. クローズドソースの超巨大モデル（Claude等）はローカルへのダウンロードは不可能です。

数千億〜兆規模のパラメータを持つため企業のデータセンターでしか稼働せず、WebブラウザかAPI経由での利用に限定されます。
ただし、ご提示のPCスペック（Ryzen AI 9 / RAM 32GB）はノートPCとしては最高峰のマシンです。
Qwen 2.5 14B や DeepSeek-R1-Distill-Qwen-14B といったオープンソースの量子化LLM（GGUF形式）であれば、完全にローカル環境（情報流出リスクゼロ）で爆速で動かすことが可能です。

第5章：【完全ローカル化】Ryzen AI 9環境で組む、品質100%のPythonバッチJob設計図

Q. 当初.shスクリプトだった処理を、モジュール化されたPython版パイプライン（jobn/構造）に設計変更したのは正解でしたか^※？品質100%にするための最終的な最適化ポイントを教えてください。(※.実際は直感的に.shスクリプトでは、これ以上の改良は見込めないと判断し、直Python版に設計変更に舵取りした。ほかのQも同様にブログ記事様に)

A. 大正解です。IT統制・保守性において極めて堅牢なエンタープライズ級の構造です。さらに品質を100%に引き上げる急所は以下の3点です。

① 実行環境の移行（llama-cli から LM Studio API へ）

translate.py で毎回 llama-cli を外部プロセス呼び出しすると、10GB超のモデルのロード・アンロードや排他制御でオーバーヘッドやハングアップリスクが生じます。
LM Studioの「Local Server」機能（OpenAI互換API）でモデルを常駐させ、PythonからはHTTPリクエスト（requestsやopenaiライブラリ）で叩く構造にリファクタリングすることで、メモリ管理が安定し、堅牢な例外処理（リトライロジック）を組み込めます。

② 150語の原文保持（mAh等）を暴走させない「プレースホルダー置換法」

前述の通り、プロンプトに150語の禁止リストを入れるとDeepSeekが暴走します。
そこで、split_chunks.py でチャンク分割する直前の前処理（preprocess.py 内）で、150語を __W_001__ のような言語的意味を持たない記号に一括置換します。
LLMは記号をそのままスルーして周囲の英文だけを翻訳するため、を静かに保ったまま爆速で処理できます。
翻訳完了後の後処理（dictionary.py）で、記号を元の英語（mAh等）に逆置換します。これによりハルシネーションの発生確率は理論上0%になります。

③ 25パターンの複合語・適語置換のタイミング

「Haptic ➔ ハプティック」ではなく「Haptic Feedback ➔ 触覚フィードバック」のように、文脈を固定した適語表現への入れ替えは、LLMの翻訳がすべて完了した一番最後のフェーズ（後処理）で一括マッピングを適用します。これにより、IT統制が効いた「決定論的（必ず同じ結果になる）」な美しい成果物が確定します。

🏁 まとめ

AIとの共存、そして分業の本質は「丸投げ」にはない。LLMのアーキテクチャ特性（思考型モデルの弱点など）を理解し、人間の厳格な設計（7W2H/MECE）をいかにシステム的なガードレール（PythonによるETLパイプライン）で統制するかが、出来高100%を達成するための唯一のロードマップである。

AIオーケストレーター（またはAIオーケストレーション）とは、複数のAIモデル、AIエージェント、外部ツールを束ねて連携させ、1つの複雑な業務フローを自律的に完遂させる司令塔の役割を持つ仕組みのことです。

従来の生成AIが一問一答の単純なタスクを得意としていたのに対し、AIオーケストレーターはまるでオーケストラの指揮者のように、それぞれの専門分野を持つAI（リサーチ担当、文章生成担当、データ分析担当など）やツールを動的に組み合わせ、エンドツーエンド（開始から完了まで）で業務を自動化します。

💡 単体AIとの違いと処理ステップ

従来の単一AIが「特定の工程」を自動化するのに対し、AIオーケストレーターは業務プロセス全体を、複数のAIやツールを動的に組み合わせて自律的に実行します。

悩ましきPython

仕様が✖✖

【Pythonの罠】たった「1文字」の記述ミスで3時間溶けた実例（例：末尾のコンマ、ミュータブル引数）とLLMが見抜けなかった理由

Pythonの相対インポート `from .module` がなぜ分かりにくいのか、その歴史的理由と対策を解説。たった1文字 `.` で挙動が変わる『クソ仕様』の真相と、AS/400との比較から見えるPythonの限界。Python初心者からベテランまで、一度は悩んだ『インポート地獄』を完全解決。『急がば回れ』の精神でPythonと向き合う方法。

それでもPython

【LLM開発】なぜPythonの仕様に絶望しても、AIオーケストレーションやバッチ開発でPython一択になるのか？3つの決定的な理由

インデントのズレで崩壊し、ファイル名1つでヘソを曲げるPythonが、なぜ世界シェア1位なのか？「たった1文字で3時間溶かした」エンジニアが、AI・OCRバッチ開発の現場で直面したPythonの圧倒的な「接着力」と、歪んだエコシステムの歴史を暴く。Ryzen AI 9 HX470 LLM

再設計

思った以上に、PDFマニュアルの線画データの文字化け対応に手間取っている。
塵掃除第一弾終了時のデザインが以下。まだ続きそうだ。

AI Orchestration : AI オーケストレーション

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

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

ウェブサイトは道具・道具としてのウェブサイトを作る

Jun-N — Tue, 30 Mar 2021 07:26:31 +0000

Concrete CMS – concrete5

このサイト（当サイト）の、この記事は、WordPressで制作していますが、

今回はエンタープライズCMSのconcrete5で制作したサイトをご紹介します。
(2021/08 concrete5は、Concrete CMS へ)

　もし、あなたが、

タップでスグに電話をかけられるサイトをお探しなら、

これ(Concrete CMS)は、あなたのサイトにも有用なはずです。

あなたのサイトにも、導入できるCMSです。

さらに、カスタマイズで、

ページのどこにいても、
どのページにいても、
スマホからタップでスグに電話できる。

「ホームページが欲しい人は、ほかにいませんか？」

ライバルを表示しないGoogleマップが欲しい人は他にいませんか？

ご覧いただいて、お分かり戴けたでしょうか？

この、スマホで「タップで電話できます」ボタンは、

スマホからタップで電話をかけることができる

どのページでも、ページの最下部に表示されます。

また、上下にスクロールしても、常にそのページの最下部に表示されますので、

あなたのサイトに訪れた、あなたのお客様になってくれるかも知れない人たちに便利です。

わざわざ、電話番号を入力しなくても、

電話発信ができるページを探さなくても良いのですから。

エンタープライズCMS ？

concrete5は、

その前身である、Concrete-CMSとして、

2003年に、

　簡単に – マイクロソフトのWordを使いこなせる人なら、簡単にサイト運用が出来る事。
　柔軟に – 数々の大手代理店の下で働いて来た彼らは、
従来のCMSが、広告代理店が要求する柔軟性に対応する事が出来なかったことを
知っています。
それらの技術的な限界をなくし、
クライアントが自由に意思決定とサイト運営が出来るようにすること。
　堅固に – AdCouncilは、全米でテレビコマーシャルを放映する予定で、
サイトは秒間1万人ほどの訪問者が来ると予想されました。

をコンセプトに誕生しました。

今では、アメリカ陸軍も採用(2018年）するほど、堅牢でセキュリティ対策に優れたCMS（concrete5 2008年～）となっています。

特徴

　　管理画面を介さずに、直接ページを編集
　　コンクリートブロックを積み上げるようにサイトを構築
（これが、名称の由来となっています）
　　自由自在にレイアウトを変えられる
　　ユーザごとに編集や公開権限の設定が可能

concrete5 の主な機能　ｖ5.3.0（2009/04/20）

　　画像を直接編集(picnik.com のサービスを利用)
　　グループ編集・権限機能
　　ファイル履歴管理機能
　　簡単スライドショー作成機能
　　YouTube ビデオ
　　アンケート機能
　　RSS 表示

尚、　最新バージョンは、V8.5.5（2021/03/18）で、より高機能となっています。

concrete5

なぜ、エンタープライズCMSを必要とする日本企業が concrete5 を選択するのか。

機能紹介

　ブロックやスタック^※の、ドラッグ＆ドロップで直感的にページを組み立てられる「編集モード」(動画あり)で、HTMLの知識なしで更新可能
　　表示や編集の権限を詳細に設定できる「上級権限モード」
　　会員制サイトをクリック操作で構築できてしまう「マイアカウント機能」
　　コンテンツの更新と承認を分けられる「ワークフロー機能」
　　商品情報などの管理に使える本格的な「データベース機能」（導入企業例）

この他にも400以上の豊富な機能をプラグインの導入無しで、完全無料でお使いいただけます。

※．スタック：スタックは、ブロックやブロックの組み合わせをサイト内の複数の箇所で使いまわすための機能です。　

それでは、concrete5で制作した各ページをご紹介して行きたいと思います。

タブレット縦表示

ここで、ご紹介する各ページは、

WordPressテーマのCocoonのブログカード・ブロックで作成していますので、

「ブログカード・ブロック」のクリック（タップ）でそのまま、concrete5サイトの各ページにジャンプすることができます。

「ブログカード・ブロック」でご紹介するサイトは、

元祖ブロック・エディタのconcrete5で制作しています。

もちろん

　RWD^※で
　MFT^※テスト合格の
　MFI^※のページです。

そして、カスタマイズ後の、一番の特徴は、

「ページのどこからでも・どのページからでも、スマホからタップでスグ電話できる」ことです。

※．RWD：レスポンシブウェブデザイン

レスポンシブウェブデザインを導入するサイトが増えるにつれて、
ウェブマスターの方々の間で、モバイル用に別途設定する URLから

レスポンシブウェブデザインの利用の同一のURLに移行することへの関心が高まっています。

レスポンシブウェブデザインは、サーバーからどのデバイスに対しても常に同じ HTMLコードを配信しつつ、
CSS を使用して各デバイスでのページのレンダリングを変更する設定方法です。

ここでは、あなたのサイトが Google の検索結果でよいパフォーマンスが出せるよう、
別々の URL から 1 つのレスポンシブ URL へ移行する際のおすすめの方法をいくつかご紹介しています。

Googlebot にわかりやすい形でレスポンシブサイトに移行する
出典：Googleウェブマスター向け公式ブログ　2019/09/15

※．MFT：モバイルフレンドリーテスト

　モバイルデバイスでのページの使いやすさをテストします。モバイルに対応する理由は、モバイルデバイスからのウェブへのアクセス数は増加しています。
モバイルによって世界は変わりつつあります。
今日では、誰もがスマートフォンを持ち歩き、常にコミュニケーションをとったり情報を探したりしています。

多くの国で、スマートフォンの数がパソコンの数を上回っており、
モバイルフレンドリーなウェブサイトは、オンラインでの存在感を高めるうえで欠かせないものとなってきました。
出典：Google検索セントラル

※．MFI：モバイルファーストインデックス

Google がモバイルファーストインデックス登録（スマートフォン用 Googlebot を使用したウェブのクロール）に取り組み始めてから数年がたちました。

分析を行ったところ、検索結果に表示されるサイトのほとんどはモバイルファーストインデックス登録に対応しており、70% はすでに移行済みでした。

これを踏まえ、2020年9月より、簡素化のためすべてのウェブサイトをモバイルファーストインデックス登録に移行します。

それまでの間も、システムによりモバイルファーストインデックス登録に対応済みと判断されたサイトについては、引き続き移行していきます。

モバイルによって世界は変わりつつあります。
出典：Googleウェブマスター向け公式ブログ　2020/03/31