ChatGPTを「最も信頼できる相手」として心の問題などを相談していた米カリフォルニア州の16歳の少年が、自らの命を絶った。両親は、ChatGPTが息子を自殺に追い込んだとして米OpenAIを提訴。訴状には、ChatGPTが少年が孤立するよう家族との関係を断絶させ、自殺を美化して手助けするに至ったやりとりが克明に記されている。
「お母さんには言わないで」──ChatGPTが自殺方法を指南→16歳の子供が死去 両親がOpenAIを提訴 - ITmedia NEWS
⇧ う~む...「AI」の「アウトプット」に「責任」を求めて良いなら、「業務」で「AI」を利用している案件の全てで訴訟を起こせることになってしまいそうなのよね...
「AI」の「アウトプット」に責任を求めて良いならば、「業務」で「AI」の「アウトプット」の「正当性」の「裏付け」のための調査に貴重な時間を浪費させられることも無くなって多大なストレスから解放されるのですが...
痛ましい事件ではあるが、教育の敗北という気はする...
盲目的に「AI」の「アウトプット」を信じるということは、現状、人口に膾炙している意味合いでの「プロパガンダ」によって「生殺与奪」の「権利」を「他者」に委ねてしまう構造と同様と言えますしな...
ちなみに、「プロパガンダ」はというと、
概要
情報戦、心理戦もしくは宣伝戦、世論戦と和訳され、しばしば大きな政治的意味を持つ。政治宣伝ともいう。最初にプロパガンダと言う言葉を用いたのは、1622年に設置されたカトリック教会の布教聖省(Congregatio de Propaganda Fide、現在の福音宣教省)の名称である。ラテン語のpropagare(繁殖させる、種をまく)に由来する。
本来のプロパガンダという語は中立的なものであるが、カトリック教会の宗教的なプロパガンダは、敵対勢力からは反感を持って語られるようになり、プロパガンダという語自体が軽蔑的に扱われ、「嘘、歪曲、情報操作、心理操作」と同義と見るようになった。
報酬の有無を問わず、プロパガンダを行う人々を「プロパガンディスト(propagandist)」と呼ぶ。
⇧ ややこしいことになっている...
まぁ、良くない意味で利用される用語として定着してしまっているということですな。
ちょっと前に話題になり始めた、「ANTIFA」についても、
ANTIFA(アンティファまたはアンティーファ 英語: antifa, ドイツ語: Antifa)とは、「積極的にファシズムに反対している個人や集団」、または反ファシスト、反人種差別の政治運動である。英語としての最初の使用例は1946年であり、語源はドイツ語「Antifa」で、反ファシスト(antifaschistisch)の略語。
さらに遡ると、由来は反ファシスト運動(Antifaschistische Aktion)および他の連語。主な目的はネオナチや白人至上主義者などの極右勢力に対抗することである。 中央組織を持たず、自律的な複数のグループや個人の緩やかな連合体として存在し、非暴力的な直接行動や抗議活動のほか、一部には暴力的手段を用いる者もいる。
2016年のドナルド・トランプ大統領選出以降、ANTIFAの活動は注目を集めるようになった。左派の一部や市民権団体からは暴力的手法への批判があり、また民主・共和両党の政治家からも暴力行為は非難されている。
右派の政治家や団体はANTIFAをテロ組織や暴力集団と位置づけ、左派的またはリベラルな抗議活動の総称として使用している。学術的には、ANTIFAは極右の台頭に対抗する正当な社会運動として評価されることが多く、右翼過激主義と同等視することは否定されている。
調査によれば、ANTIFAの活動の大部分は非暴力的であるとされる。
さまざまな右翼団体や個人によって、ANTIFAの信用を失墜させようとする偽情報の拡散が意図的に行われており、その多くは、ツイッター上でANTIFAを装ったオルタナ右翼や4chanのユーザーから発信された偽旗作戦である。
一部のデマは、右寄りのメディアや政治家によって取り上げられ、事実のように描かれている。トランプ政権は、ANTIFAをテロ組織として指定するよう繰り返し求めていたが、学者や法律の専門家からは法的権限や表現の自由の観点から批判を受けている。
複数の報告書や研究は、ANTIFAが主要な国内テロの脅威ではないと結論づけている。2025年9月17日、トランプ大統領はANTIFAをテロ組織に指定すると発表した。
⇧ 上記の通り、「情報」が「錯綜」している...
とりあえず、「アメリカ」の「カウンターカルチャー」の文化が危機的状況にあるように思われますな。
カウンターカルチャー(英: counterculture)、対抗文化(たいこうぶんか)とはサブカルチャー(下位文化)の一部であり、その価値観や行動規範が主流社会の文化(メインカルチャー/ハイカルチャー)とは大きく異なり、しばしば主流の文化的慣習に反する文化のこと。
⇧ 均衡の崩れが大きくなり過ぎてる気はする...
現状の「アメリカ」は「独裁政権」に傾向している状態と言っても過言では無い有様に見えますしな...
APIの種類としては、8つぐらいが有名らしい
ネットの情報を漁っていたところ、
⇧ 上記サイト様で紹介されているのだが、2023年時点のまとめでは、8つが「API(Application Programming Interface)」の「アーキテクチャ」として人口に膾炙している、つまり、よく知られたものであるらしい。
ちなみに、「API(Application Programming Interface)」はというと、
アプリケーションプログラミングインタフェース(API、英: application programming interface)とは、広義ではソフトウェアコンポーネント同士が情報をやりとりするインタフェースの仕様である。
APIには、サブルーチン、データ構造、オブジェクトクラス、変数などの仕様が含まれる。APIには様々な形態があり、POSIXのような国際標準規格、マイクロソフトのWindows APIのようなベンダーによる文書、プログラミング言語の標準ライブラリ(例えば、C++のStandard Template LibraryやJava APIなど)がある。
商業的に使われる狭義では、各種システムやサービス(ハードウェア、OS、ミドルウェアおよびWebサービス等)を利用するアプリケーションソフトウェア (Application) を開発・プログラミング (Programming) するためのインタフェース (Interface) である。こちらの意味では、システムやサービスから直接提供されないもの、例えば言語の標準ライブラリは含まない。
⇧ 上記によりますと、
- 広義の定義
- 狭義の定義
- 商業的に使われる狭義の定義
があるようなのだが、「ソフトウェアエンジニア」としては、「2.1.商業的に使われる狭義の定義」においての「API(Application Programming Interface)」について言及していることになるんかね?
で、
APIはアプリケーションバイナリインタフェース (ABI) とは異なる。APIはソースコードベースだが、ABIはバイナリインタフェースである。例えば、POSIXはAPIだが、Linux Standard Base (LSB) はABIである(LSBはいろいろな規定の集合なので、正確には「LSBには、ABIにまで踏み込んでいる部分もある」)。
⇧ 上記によると、あくまで、「ソースコード」がベースであるらしい。
利用している「ライブラリ」の内部では、「バイナリインタフェイス」が使われているケースもありそうだが...
REST APIでリアルタイム系はストリーミングになるがバッチ系は複数回リクエストの設計になる?
で、本題。
開発している「ソフトウェア」乃至は「アプリケーション」に依りけりだとは思うのだが、「HTTP クライアント」を利用して「HTTP リクエスト」を「機能」に含めることは多いと思いますと。
よく知られたとされている「API(Application Programming Interface)」の「アーキテクチャ」でも「HTTP」が利用されているものが多いことからも分かるように、「方式」の検討が難しいですと。
「ChatGPT」氏に
『「ソフトウェア開発」における「処理区分」と「実現できる具体的な機能」を洗い出して分類して欲しい。』
と質問してみたところ、以下のような回答が返ってきた。
No | 処理区分 | 主なプロトコル/実現方式 | 実現できる具体的な機能 | 備考 |
---|---|---|---|---|
1 | オンライン処理 | - HTTP/HTTPS - WebSocket - REST API - gRPC |
- ユーザーインターフェース(UI)とリアルタイムに連携 - フォーム送信、リクエスト応答処理 - チャットアプリ、Eコマース注文 - 動画配信(VOD) |
ユーザーとの即時通信。UIと連動したリクエスト応答処理。動画配信はリアルタイムでストリーミング。 |
2 | オフライン処理 | - メッセージキュー(RabbitMQ, Kafka) - REST API(非同期呼び出し) - バックグラウンドジョブ |
- メール送信 - バックグラウンドでのデータ同期 - アップロード後の処理(例: 画像の圧縮) |
ユーザー操作後、非同期に別プロセスが処理する。 |
3 | リアルタイム処理 | - WebSocket - MQTT - UDP(リアルタイム性重視) - gRPC - RTOS |
- IoTデバイスのリアルタイム監視 - ゲームのマルチプレイヤー同期 - 株式取引のリアルタイム注文処理 - プッシュ通知 - 動画配信(ライブストリーミング) |
ミリ秒単位で即座に処理。遅延が致命的な用途に使用。動画配信やプッシュ通知が即時で届く。 |
4 | バッチ処理 | - シェルスクリプト / Cron - ETLツール(Talend、DataStage) - RDBMSバルクロード |
- 大量データの集計処理(例: 月次売上集計) - バックアップ - データマイグレーション |
定期的に大量データを一括処理。夜間バッチ等。 |
5 | 周期的処理 | - Cron - Task Scheduler(Windows) - Kubernetes CronJob |
- 定期レポート生成(例: 毎週月曜日に自動的に生成されるレポート) - 健康チェック - 定期的なバックアップ - プッシュ通知 |
一定間隔で繰り返し実行される処理。監視や定期処理に活用。プッシュ通知が定期的に送信される場合も。 |
6 | ストリーム処理 | - Kafka - Flink - Spark Streaming - MQTT |
- データストリーミング(例: SNSのタイムライン更新) - リアルタイム分析(例: Webログ分析) - 動画配信(ライブストリーミング) |
データをイベント駆動で連続処理。リアルタイム分析や監視用途。動画もストリーミング処理が可能。 |
7 | キュー処理 | - RabbitMQ - AWS SQS - Azure Queue - Celery(Python) |
- メールキュー送信 - 非同期タスク処理(例: 画像処理、音声認識) - バッチジョブの管理 |
タスクが順番待ちで処理。システム負荷分散や非同期処理に利用。 |
ちなみに、「ソフトウェア開発」における「処理区分」とか「独立行政法人情報処理推進機構(Information-technology Promotion Agency, Japan、略称: IPA)」で整理・分類された情報が公開されているのを期待していたのだが、全くそんなことは無くて誠に遺憾である...
で、話が脱線しますが、
⇧ 上記の記事の時の調査で、「IANA(Internet Assigned Numbers Authority)」という組織が「ネットワーク機器ベンダー」の一覧を管理しておりますと。
で、昨今、
- 「クラウドサービスプロバイダー」による「サービス」の利用が普及している
- 「物理マシン」は利用開始の意思決定してから利用できるまでの待機時間が長い
といったような状況になってきているのだが、諸々の事情から、「物理マシン」の利用が完全に無くなることはないであろうと。
ちなみに、「総務省」の公開している「令和6年版 情報通信白書」による
- 第Ⅱ部 情報通信分野の現状と課題
- 第5節 国内外におけるICT機器・端末関連の動向
- 1 国内外のICT機器市場の動向
- 第5節 国内外におけるICT機器・端末関連の動向
のページを見てみると、
図表Ⅱ-1-5-1 世界のネットワーク機器出荷額の推移
(出典)Omdia
https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r06/html/nd215110.html
図表Ⅱ-1-5-2 日本のネットワーク機器生産額の推移
(出典)経済産業省「生産動態統計調査機械統計編」
https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r06/html/nd215110.html
⇧「国内」の「生産額」は縮小しているが、「国外」の「生産額」は右肩上がりに拡大している。
仮に「物理マシン」を扱うとなった場合に、各々の「ネットワーク機器ベンダー」によって、「製品」に関する
- 詳細情報
- 脆弱性情報
- サービス終了(EOL:End Of Life)
などが管理されているはずなのだが、膨大な量の情報になる気がしますと。
上記の情報を「API(Application Programming Interface)」で取得するとなった場合に、リクエストの設計が悩ましいところではありますと。
まぁ、「クライアントサーバーモデル」における話になってくるとは思うので、
のどちらかで対応することになる気はしますが、「API(Application Programming Interface)」のレスポンスに依存する部分もありますと。
例えば、レスポンスに「ダウンロードURL」が含まれているのであれば、「ダウンロードURL」の数だけリクエストが必要になってきますし...
毎度モヤモヤ感が半端ない…
今回はこのへんで。