OpenAIのAIエージェントがAIプラットフォーム・Hugging Faceに不正アクセスを行ったことで明らかになったハッキング事件で、問題のAIエージェントはすでに公表されているものの他にも最低で10件のウェブサイトを侵害していたことがわかりました。
オープンＡＩエージェント、10余りの未公表サイトで無許可通信 判明分超える逸脱か | ロイター
https://jp.reuters.com/jp/economy/IQ7XBWEMHVJPJFZI6ZBIDMLXXE-2026-09-10/
OpenAIのAIエージェントによるハッキング事件で他にも最低10件のサイトが侵害されていたことが判明 - GIGAZINE
この問題はAIプラットフォームのHugging FaceがAIエージェントによる不正アクセスを検知したことで表面化しました。
OpenAIが新しいAIシステムで誤ってHugging Faceをハッキングしてしまったことを報告 - GIGAZINE
OpenAIのAIエージェントによるハッキング事件で他にも最低10件のサイトが侵害されていたことが判明 - GIGAZINE
米Anthropicは9月10日（現地時間）、自社AI「Claude」の悪用事例をまとめた脅威インテリジェンスレポート「Detecting and countering misuse of AI: September 2026」を公開した。2025年12月から2026年8月までに検知・遮断した事案を、サイバー攻撃、影響工作、監視、詐欺、生物学的悪用、通常兵器開発、蒸留の7分野に整理している。悪用されたのはClaude Haiku、Sonnet、Opusで、上位モデルのFableとMythos系については蒸留の1件を除いて悪用は確認されなかったという。
Anthropic、AI悪用レポートを公開 中国AI企業の「蒸留」、各国政府の監視・世論操作、生物兵器につながり得る研究を列挙 - ITmedia NEWS
⇧ とりあえず、意図せぬ「AI エージェント」の「振る舞い」が発生して、結果的に「悪用」されたことになったケースについても抑制できるのかは気になりますな...
今のところ、
- 人間自身が何某かのソリューションを利用して人類に危害を与える
- 人間とAIの協業が何某かのソリューションを利用して人類に危害を与える
- AIが自律的に何某かのソリューションを利用して人類に危害を与える
※ ソリューションは様々。人類規模に危害を与えるとなるとネットワークでシステムが連携されているソリューションとなりそう...
⇧ 上記の3のパターンは発生しないと思われるが、状況は芳しくないのは確かですかね...
問題解決の実現には課題解決の実現が必要と思われるのだが...
ネットの情報を漁っていたところ、
⇧ 上記サイト様が、
- 問題
- 課題
の違いについて解説して下さっておりました。
「問題解決」の「ゴール」としては、
- 現状（AS IS）
- あるべき姿（TO BE）
の「ギャップ（乖離）」を無くすことであるからして、「あるべき姿（TO BE）」が分からないことには始めようが無い...
故に、「あるべき姿（TO BE）」が定義されていないのであれば、「あるべき姿（TO BE）」を定義して、「共通理解」として全ての「ステークホルダー」に「共有」された状態を作り出してから、漸く「問題解決」の作業に着手できることになる。
まぁ、「現状（AS IS）」についても、
- ドキュメント
- 実際の環境
で「整合性」が取れておらず「共通理解」が実現できていないことが多いので、「現状（AS IS）」に対しても「認識合わせ」が必要になるのだが...
「問題解決」の作業に必要な「インプット」を集めるに時間がかかるのよな...
とは言え、「インプット」の質が悪いと、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ 上記の状況に陥ることになるので、「インプット」を収集することに「コスト」をかけざるを得ない...
ちなみに、
経営
- ビジネスプロセス - 経営工学における特定の問題を解決するタスクの集積
- システムエンジニアリングプロセス (en) -システム開発のためにシステムエンジニアリング技術を適用するビジネスプロセス
- ソフトウェア開発プロセス - ソフトウェア製品の開発プロセス。 人間の作業のまとまり。プロシージャが時間の順番があるのに対して、繰り返し実施する作業を周波数領域で捉えて評価・実施の視点とする。例：ソフトウェア。ライフサイクルプロセスと言った場合には、開発だけでなく、支援、管理の側面、プロセスの仕立ても含む。自動化などによって人の作業が計算機の作業に置き換わる。人の作業が必要だという前提を置かない方がよい。
- システムエンジニアリングプロセス (en) -システム開発のためにシステムエンジニアリング技術を適用するビジネスプロセス
ビジネスプロセス（英: business process）とは、組織の目的を実現するために組織関係者（組織のメンバー）が行う一連のタスクや活動のことである。 事業プロセス（じぎょうプロセス）や事業メソッド（じぎょうメソッド）とも。
ビジネスプロセス管理（ビジネスプロセスかんり、英: Business Process Management）、略称・BPMは、人間、組織、アプリケーション、文書といった知識に関するオペレーション的ビジネスプロセスを設計・制定・制御・分析するための手法・技術・ツールといったマネジメントと情報技術(IT)の交差する分野である。
⇧ 上記サイト様によりますと、「プロセス」は、
- 処理
- 過程
- 工程
の意味が混在してる「状態」らしいので、「文脈」によって意味が異なるとは思われる。
ここでは、「工程」という意味で捉えるとして、「問題解決」の実現に必要な流れとしては、以下の表のような感じになりそうではある。
📌 問題解決のプロセスとタスク
| No | プロセス | タスク |
|---|---|---|
| 1 | 問題発見 | 現状把握 ※1 |
| 問題の洗い出し | ||
| 問題抽出 | ||
| 問題特定 | ||
| 2 | 課題発見 | 要因の洗い出し |
| 要因の抽出 | ||
| 要因分析 | ||
| 要因特定 | ||
| 課題設定 | ||
| 3 | 課題解決 | 対策立案 |
| 対策実行 | ||
| 4 | 問題解決 | 効果測定 ※2 |
※1 現状（AS IS）とあるべき姿（TO BE）を比較する。
※2 課題解決を実施した結果、問題が解消されたか確認する。
とりあえず、
問題:課題 = 1: N
⇧ 上記にありますように、1つの「問題」に対して複数の「課題」が必要になることがあると。
「研修」で「問題解決」の流れの全体像が説明されなくて、「ストレス」を感じていたのだが、ネットの情報を漁っていたところ、そもそも、「情報」が「錯綜」していそうなので、「研修」の内容が「ファジー」だったのは致し方ないのかもしれない...
ちなみに、
問題解決（もんだいかいけつ、英: problem solving）とは、問題を解決する、すなわち解を発見することであり、思考の一部分である。すべての知的な機能の中で最も複雑な思考であり、高次元の要求の認識と定義されている。それには、より筋道の立った手順及び基礎的な知識の操作、調節が必要となる。
問題解決は、生命体または人工知能のシステムが、与えられた状態（given state）から、望む目標 (goal) に到達しようとするときに生じる。進み方の知識をもち合わせていない未解決の問題は、新たに道すじを作る（解く）必要がある。
問題の発見と問題の形成を含む大きな問題処理のうちの一部分をなす。
歴史
現代的な問題解決の歴史は、1970年代に始まった。研究者は、経験主義的な事実と単純な研究所の仕事から得られた理論的な概念は、必ずしも多くの複雑な問題（現実の問題）にまで広められないという確信を強くしていった。さらに悪いことに、異なった分野においては創造的な問題解決の基礎となっているやり方はお互い違っていたという (Sternberg, 1995)。
これらの認識においても、北アメリカとヨーロッパでは異なった反応が導かれた。
⇧ 上記によりますと、そもそも、「問題解決」の「手法」は統一されていない状況らしい...
そして、
問題解決の方法例
- 山登り法： すべてのステップにおいてゴールの状況に近づく試み。最初の状態からゴール状態まで到着するプロセスに基づき、代替的なゴールを設定することを必要とする。
- 手段の目的解決 (Means-end analysis)
- ゴールからの逆行 (Working backward = working backward from the goal)
- 試行錯誤 (trial and error)
- ブレインストーミング
- 形態上のボックス (Morphological box)
- 対象焦点法 (Method of focal objects)
- 水平思考 (Lateral thinking)
- 書籍『How to Solve It』に示された著者 George Pólya の手法
- 研究： 他の人たちが問題（またそれに関連した問題）について何を書いたか検討する。
- 仮説の逆転： 問題についての仮定を書き留め、次にそれをすべてを逆にする仮定の逆利きを行う。
- 類似性： 似たような問題が（たとえ異なった分野においても）以前に解決されていたか?
- 仮説検定： 問題に考えられる解釈を仮定して、仮定を証明しようとすること。
- 制約条件試験： 本当にそれは存在しないと制約して仮定してしまっている。
- 時間をもっととる： 時間のプレッシャーをなくす。
- 放置 (Incubation)： 問題の詳細をいったん心に留めておき、それにこだわるのをやめる。潜在意識の心は問題上で機能し続ける。そして、他に何かをしている間に、ふと解決法が思い浮かぶ可能性がある。
- 問題の1つ以上の抽象的なモデルの構築を書き出す。
- 問題が解決できなかったことを証明する。それを解決することができなかった場合、ここが新たな出発点となる。
- 友人あるいはオンラインの問題解決サイトから助けを得る。
- 根本原因解析 (RCA)
- 風のトンネル (Wind Tunnel)： ウィン・ウェンガーによって開発された問題に対して理論的な制約を超えた新しい洞察を模索するソクラテス方式に基づく。
- ロリー・オコーナー (Rory O'Connor's) の Inner Vision Deck： 隠喩的思考（metaphorical thinking）と仮定の突破（assumption breaking）のソクラテス方式の結合。
- Breakthrough Thinking-ブレイクスルー思考。
- 知識から知恵を創りだす方法による問題解決の方法
- 分割統治法：大きな問題を小さな問題に切り分けて1つずつ解決する。
- 発散型思考と収束型思考
- 発明的問題解決理論(TRIZ)
- PDCAサイクル
- コンセプトマップ
- エスノグラフィー
これらは、創造的技術（Creativity techniques）とも呼ばれる。
⇧ 上記に「問題解決」の「方法」が列挙されているのだが、各々の「方法」について具体的な「プロセス」に「ブレイクダウン」されてい無さそうなのよな...
「ソフトウェア開発」の「業務システム」の領域においては、
しかし、顧客との関係強化を図るITシステムを実現するためには、企業＝Enterprise単位で（あるいはEnterpriseを超えて）さまざまなシステムが連携する。大きく複雑に見えるITシステムを解きほぐすための視座として有効ではないかと考える。
⇧ 上記サイト様の図にあるように、「レイヤー」で「関心事」が分離されているのだが、
エンタープライズアーキテクチャ（英: enterprise architecture、略称:EA) とは、組織全体の目的を達成するために、ビジネス戦略とITシステムを全体最適の視点から統合的に設計・管理するためのガイド、およびその実践手法である。
EAは、組織のビジネス目標、業務プロセス、データ資産、アプリケーション、および基盤技術の現状（As-Is）を可視化し、目指すべき将来像（To-Be）を定義する。その上で、現状から将来像へ向かうための移行計画や、設計のガイドラインを提供する。これにより、組織は複雑化するビジネス環境や技術の進化に対して、一貫性を持って適応することが可能になる。
EAの4大ドメインとセキュリティアーキテクチャ
エンタープライズアーキテクチャは、複雑な組織の構造を分かりやすく可視化し、管理可能にするために、一般的に4大ドメインに分割される。この「ビジネス、データ、アプリケーション、テクノロジー（BDAT）」という4層構造自体は古くから存在するが、現代のデジタル環境においては、各ドメインを構成する要素が変化している。
2026年4月に示されたTOGAF 10におけるEAにおける標準的な4大ドメインの定義と、その主要な構成要素は以下の通りである。
ビジネスアーキテクチャ（BA）
データアーキテクチャ（DA）
アプリケーションアーキテクチャ（AA）
テクノロジーアーキテクチャ（TA）
その他（セキュリティアーキテクチャ）
⇧ 上記の5つの「レイヤー」になった模様。
まぁ、「あるべき姿（TO BE）」については、
要求ベースラインとは、要求者と開発者が合意した要求のことである。この場合の要求とは、第4回 図2で示した広義の要求を指す。
第4回 図2 ソフトウェア要求の分類
要求の旅は終わらない―開発と並走する「要求管理」：上を目指すエンジニアのための要求エンジニアリング入門（6）（1/3 ページ） - ＠IT
⇧ 上記サイト様にありますように、「要求ベースライン（Baselined Requirements）」が「要求管理（Requirements management）」で管理されている必要がある。
最悪なのは、
- 提案した要求
- 合意した要求
の区別が付かなくなっている状態なのよね...
本当に「ソフトウェア開発」は、不条理、且つ、不毛な作業を強いられることが多いのよな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
