Ubuntu環境でのOllamaセットアップガイド:ローカルで動作するAIアシスタントの構築

最近注目を集めているローカルで動作するLLM(大規模言語モデル)ランタイム「Ollama」のUbuntu環境での導入方法と基本的な使い方について解説する。Ollamaを使用することで、プライバシーを保ちながら、ローカル環境で高性能なAIアシスタントを利用することが可能である。

1. Ollamaとは

Ollamaは、オープンソースのLLMランタイムで、以下のような特徴を持つ:

  • ローカル環境で動作する(インターネット接続不要)
  • 様々なオープンソースモデルに対応
  • APIを通じた柔軟な利用が可能
  • システムリソースの要件が比較的低い

2. システム要件

Ollamaの動作には以下のようなシステム要件が必要である。

What are the minimum hardware requirements to run an ollama model? あたりの情報を参考に。

2.1 基本要件

  • RAM:
    • 7Bパラメータモデル: 最低8GB RAM
    • 13Bパラメータモデル: 最低16GB RAM
    • 70Bパラメータモデル: 最低64GB RAM

2.2 推奨スペック

  • CPU: AVX512対応のIntel/AMD CPU、もしくはDDR5対応プロセッサ
  • RAM: 16GB以上
  • ストレージ: 約50GB以上の空き容量

2.3 GPU要件(オプション)

  • NVIDIA GPU: ドライバーバージョン452.39以上
  • AMD GPU: 最新のRadeonドライバー

なお、実際の必要スペックは使用するモデルのサイズや用途によって大きく異なる。特に大規模なモデルを使用する場合は、より多くのリソースが必要となる点に注意が必要である。

3. インストール手順

Ubuntu環境でのインストールは非常に簡単である。以下のコマンドを実行する:

1
curl -fsSL https://ollama.com/install.sh | sh

インストール後、システムサービスとして登録し、自動起動を設定する。なお、手元の環境では最初から下記の環境設定が完了していたので不要かもしれない。:

1
2
systemctl start ollama
systemctl enable ollama

正常にインストールされたことを確認する:

1
systemctl status ollama

4. 基本的な使い方

4.1 モデルのダウンロード

最初に使用したいモデルをダウンロードする必要がある:

1
2
3
4
5
6
7
8
# Llama 3モデルをダウンロード
ollama pull llama3

# 利用可能なモデルの確認
ollama list

# NAME ID SIZE MODIFIED
# llama3:latest 365c0bd3c000 4.7 GB 6 seconds ago

4.2 対話モードでの利用

1
2
# 対話モードでモデルを起動
ollama run llama3

4.3 APIとしての利用

Ollamaは11434番ポートでHTTP APIを提供している:

1
2
3
4
curl -X POST http://localhost:11434/api/generate -d '{
"model": "llama3",
"prompt": "Ubuntuの主な特徴を3つ挙げよ"
}'

5. カスタマイズと応用

5.1 システムプロンプトのカスタマイズ

Modelfileを使用して、モデルの振る舞いをカスタマイズすることができる:

1
2
3
4
5
6
7
8
# Modelfileの作成
cat << EOF > Modelfile
FROM llama2
SYSTEM "あなたはLinuxシステムの専門家である。Ubuntuに関する質問に詳しく答えよ。"
EOF

# カスタムモデルの作成
ollama create ubuntu-expert -f Modelfile

5.2 環境変数の設定

必要に応じて以下のような環境変数を設定する:

1
2
3
4
5
# GPUメモリ制限の設定
export CUDA_VISIBLE_DEVICES=0

# リモートアクセスを許可
export OLLAMA_HOST=0.0.0.0

6. セキュリティ設定

6.1 ファイアウォールの設定

UFWを使用している場合は、必要なポートを開放する:

1
2
sudo ufw allow 11434/tcp
sudo ufw status

6.2 アクセス制限

特定のIPアドレスからのみアクセスを許可する場合の設定:

1
2
3
# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_HOST=192.168.1.100" # 特定のIPアドレスを指定

7. トラブルシューティング

7.1 ログの確認

問題が発生した場合は、以下のコマンドでログを確認する:

1
2
3
4
5
# システムログの確認
journalctl -u ollama -f

# サービスのステータス確認
systemctl status ollama

7.2 一般的な問題の解決

1
2
3
4
5
# サービスの再起動
systemctl restart ollama

# キャッシュのクリア
rm -rf ~/.ollama/cache/*

8. 参考情報とリソース

公式リソース

  • Ollama 公式サイト
    • 最新のドキュメントと更新情報
    • モデルのダウンロードとライブラリ
  • Ollama GitHub
    • ソースコードとイシュートラッキング
    • コミュニティの貢献とディスカッション

モデル関連

  • Llama 2
    • Meta社による基本モデルの詳細
    • ライセンスと使用条件

コミュニティリソース

  • Ollama Discord
    • コミュニティサポート
    • ユースケースの共有
  • Ollama Reddit
    • ユーザーディスカッション
    • トラブルシューティングのヒント

関連プロジェクト

  • LangChain
    • Ollamaとの統合例
    • アプリケーション開発フレームワーク

まとめ

Ollamaを使用することで、プライバシーを保ちながらローカル環境で高性能なAIアシスタントを利用することが可能となる。 この記事で紹介した設定や使い方を参考に、各自の環境に合わせたAIアシスタントの構築を検討されたい。

共有

AMDのGPUメモリ量を変更する

AMDのGPUメモリ量を調整する方法について説明する。

  1. まず、AMD Softwareを起動する。
  2. 画面上部にある「パフォーマンス」タブをクリックする。
  3. 続いて「チューニング」タブを選択すると、専用グラフィックメモリの設定画面が表示される。
  4. ここで必要に応じてメモリ量を調整することができる。

この設定を変更する際は、システムの安定性に影響を与える可能性があるため、慎重に行う必要がある。

共有

Consideration of the Usefulness of Data Spaces and Data Collaboration Infrastructure in the Healthcare Field

1. はじめに

近年、医療分野におけるデジタルトランスフォーメーション(DX)の推進が加速しており、特に電子カルテをはじめとするデータ連携基盤の整備が注目されている。政府は2025年度を目途にクラウド型病院システムの「標準仕様」を示し、2030年までに希望する医療機関が導入可能な環境を整備する計画を進めている。この取り組みにより、医療情報の効率的な管理と共有が期待されている(参考文献:病院の電子カルテ等のクラウド化・共有化、2025年度目途に国が | GEMMED)。

さらに、2025年には全国医療情報プラットフォームが運用を開始する予定であり、これにより医療機関間での情報共有が円滑化されることが期待されている。このプラットフォームは、地域医療の質向上と患者の利便性向上に寄与する重要な役割を果たすとされている(参考文献:全国医療情報プラットフォームの役割とは | CBパートナーズ)。

また、「医療DX令和ビジョン2030」では、2024年の診療報酬改定を踏まえつつ、2026年を見据えた包括的な取り組みが進められている。このビジョンは、医療の質の向上と効率化を目指し、デジタル技術を活用した新しい医療モデルの構築を目指している(参考文献:医療DX令和ビジョン2030のこれまでとこれから~2026年への備え | 富士通)。

本稿では、これらの背景を踏まえ、医療DXの推進における課題と展望について考察する。


2. 医療業界におけるデータ連携に関連する課題

2.1 挙げられてきた課題(現在取り組まれているものも含む)

  1. データの断片化
    • 医療機関ごとに異なる電子カルテシステムやデータフォーマットが使用されており、データの統合が困難。

    • 診療履歴、検査結果、投薬情報などが一元化されていない。

      参考文献:医療DX令和ビジョン2030 | 厚生労働省

  2. 地域間・機関間の連携不足
  3. データ活用の制約

2.2 医療業界特有の課題(現在取り組まれているものも含む)

  1. データ標準化の遅れ
  2. プライバシーとセキュリティ
  3. 中小医療機関のリソース不足

3. 電子カルテ情報及び交換方式の標準化の現状

3.1 推進されている取り組み

  • HL7 FHIRの採用:医療機関間やシステム間でのデータ交換を円滑にするため、国際標準規格であるHL7 FHIR(Fast Healthcare Interoperability Resources)を用いたAPI接続の仕組みが検討・実装されている。この規格により、異なるシステム間でのアプリケーション連携が容易になる。参考文献:電子カルテ等の標準化について
  • クラウド型電子カルテの普及:2025年度を目途に、国がクラウド型病院システムの標準仕様を提示し、2030年までに希望する医療機関が導入できる環境を整備する計画が進行中である。参考文献:クラウド型病院システムの標準仕様
  • 標準化のガイドライン作成:電子カルテ情報の標準化を効率的に進めるため、国民、医療機関、保険者などの関係者が協力し、具体的なガイドラインが作成されている。参考文献:資料1:電子カルテ情報及び交換方式の標準化

3.2 課題と制約

  1. 導入コスト:電子カルテの導入には初期費用が大きく、特に中小規模の医療機関にとっては大きな障壁となっている。参考文献:電子カルテを標準化する4つのデメリット | Clinics Cloud
  2. 運用の複雑化:電子カルテ導入後、操作方法の習得や運用の慣れに時間がかかることが課題である。参考文献:地域医療におけるDX化のメリット・デメリット | FastDoctor
  3. 地域間格差:都道府県別の電子カルテ導入率に大きな差があり、都市部と地方部での普及状況が異なる。参考文献:医療関連企業向け|統計からみる市場動向 ~電子カルテの導入状況 | NKグループ

4. ナショナルレベルのデータ連携基盤の意義

4.1 患者中心の医療の実現

  • 診療履歴の一元管理患者の診療履歴や検査結果を一元化することにより、重複検査や治療を回避することができる。また、患者が異なる医療機関を受診した場合でも、必要な情報が即座に共有され、医療の質が向上する。この一元管理は、電子カルテや医療情報システムの活用により実現されている。他業界では、ERPによる一元管理が成功例として挙げられる。医療情報システムを専門とする企業も増えており、協調領域をナショナルレベルで標準化することで、社会全体のコストを抑えながら効果的な一元管理を実現できると考えられる。参考文献:医療業界向けERPはなぜ重要か医療情報システムとは?
  • 遠隔医療の推進地方や医師不足地域において、データ連携基盤を活用した遠隔医療が可能となる。患者データに基づく精度の高い診断と治療が実現し、異なる法人やシステム間で患者情報を統合する取り組みが進行中である。既存サービス、製品の中にも、異なる法人(システム)の患者情報を自動収集、統合することを例として挙げているものもある。参考文献:Vol.3 医療データ活用に向けた、患者情報の統合・一元管理

4.2 医療費削減と効率化

  • 医療資源の最適配分データ分析により、地域ごとの医療需要を予測し、医療資源を効率的に配分することが可能である。また、医療機器や薬剤の在庫管理を効率化することで、医療機関内外での資源の無駄を削減できる。これを企業横断的に実施することで、緊急時に企業間で資源を融通し合える体制が構築され、危機に強い社会の実現につながると考えられる。参考文献:医療業界向けERPはなぜ重要か 重複診療や不要な治療の削減

データ共有により、患者の診療記録や検査結果が即座に参照可能となり、無駄な医療費を削減する。院内のケースでは、診療録管理システムなどの導入により、これらの効率化が進んでいる。これを企業や病院を横断して実現することで、過去の患者記録に即した無駄の排除が可能であると考えられる。特に、異なる法人や病院をまたいだデータ連携は、患者が複数の医療機関を利用する際に診療の重複を防ぎ、より迅速かつ正確な診療を可能にする。このような取り組みは、地域医療連携ネットワークや国際的な標準規格(例:HL7 FHIR)を活用したデータ共有システムによっても推進されると考えられる。

参考文献:


4.3 医療データの利活用

以下では、医療データの利活用による改善事例を紹介する。これらの事例は必ずしもナショナルレベルの取り組みではないが、協調領域での共同の取り組みにより、二つの重要な効果が期待できる。一つはデータ量の増加による利活用効果の向上、もう一つは協調領域におけるコスト削減である。


5. 他分野の事例を医療分野に応用する可能性

5.1 ウラノスエコシステム

概要

ウラノスエコシステムは、日本政府が推進するデータ連携基盤構築の一環であり、官民協調によるデータ共有と利活用を目指した取り組みである。特に業界横断的なデータ連携を可能にすることを目的としている。

特徴

  1. 業界横断的なデータ連携政府、防災、教育、医療、産業など、複数の分野でデータを連携させる仕組みを構築している。これにより、国境や業界を超えたデータの統合が可能となる。 参考文献:
  2. 標準化と相互運用性データ共有には規格や標準が必要であり、ウラノスエコシステムはこれらも考慮した基盤として設計されている。これにより、異なる組織間でもデータの互換性を確保する。現在の事例は主に製造業を中心としたものだが、考え方自体はそれに特化したものではない。 参考文献:

5.2 DATA-EX

概要

DATA-EXは、分野を超えたデータ連携を目指すプラットフォームを実現するイニシアティブであり、データ提供者と利用者の間で安全で信頼性の高いデータ流通を実現することを目的としている。医療に強く関連がある議論として、DATA-EXの取り組みの中では、匿名化技術とアクセス権限管理を通じてデータセキュリティを高めるための議論も行われている。

匿名化技術やアクセス制御に関する議論

  1. 匿名化とプライバシー保護データの匿名化技術を活用し、個人情報を保護した形でのデータ共有を実現する。これにより、医療研究や臨床試験におけるデータ利用が促進される。
  2. アクセス権限管理とセキュリティデータ利用者ごとに異なるアクセス権限を設定することで、データの不正利用を防ぐ。この仕組みは、医療従事者や研究者が関与する複雑な医療データ管理に適している。

参考文献: データ社会アライアンスのホワイトペーパー

5.3 医療分野への適用可能性

  • 応用可能性
    • 既存の国内のデータ連携基盤は、多様なデータを共有する仕組みを想定している。医療情報(電子カルテ、診療データ、地域医療情報など)を含むデータ共有、医薬品や医療機器の研究開発、公衆衛生の向上に寄与する可能性がある。
    • DATA-EXで議論されているような匿名化技術やアクセス管理技術を応用することで、患者データの匿名化とアクセス権管理を基盤にした安全なデータ流通を実現できる可能性がある。これは、医療研究機関や製薬企業とのデータ連携を容易にし、イノベーションを促進する。
  • 課題と制約 ただし現在の適用事例では考慮されていない、医療関係固有の課題も想定される。以下に例を挙げる。
    • 医療データの特殊性(例:法規制、プライバシー保護の厳格さ)。
    • 医療機関間でのシステムの互換性や導入コスト。
    • データ利用における透明性と倫理的課題。
    • 医療データの匿名化技術の具体的な利用例が不足している。
    • 医療従事者や研究者間でのデータ共有における透明性と倫理的課題。
    • データ管理コストや技術導入の負担。

参考文献:


6. 医療業界における標準化の具体策

6.1. データ連携基盤と医療関連の国際標準の連携

6.1.1 FHIRとデータ連携基盤

FHIRは、医療データの共有と相互運用性を高めるために開発された国際標準であり、以下の点でデータ連携基盤と密接に関連する:

  • データ交換の効率化:FHIRのリソース形式はRESTful APIを採用しており、既存のデータ連携基盤の多くが対象としているデータプレーンプロトコルとの親和性がある。また、将来的にリアルタイムで医療情報を交換する際の発展にも期待できる。
  • 異種システム間の相互運用性:医療機関が異なるシステムを使用していても、FHIRを基準とすることで、データ形式の統一が可能となる。製造業のサプライチェーンにおける事例でもデータのスキーマに関する議論がありガイドラインとなっていたが、同様のことを医療業界においても考えることができる。

6.1.2 プロトコル標準化の重要性

データ連携基盤が効果的に機能するためには、FHIRのような医療業界における国際標準を包含する、あるいは対応したプロトコルの標準化が不可欠である。

  • 国内外の調和:国際標準を国内基盤に適用する際、日本独自の事情を考慮した医療データ標準化ガイドラインを策定し、国際規格との整合性を保つ必要がある。また、他業界(例:保険業界、製薬業界、IT業界)で用いられるデータ標準やプロトコルとも整合性を図り、医療データが多様な分野で活用される環境を構築する。
  • セキュリティとプライバシー:標準化されたプロトコルには、データ匿名化やアクセス権限管理の仕組みが組み込まれるべきである。これにより、個人情報保護法への適合が確保されるだけでなく、他業界とのデータ連携においても安全性が保証される。たとえば、保険業界との連携では、患者の同意のもとで匿名化された医療データを活用し、保険商品の開発やリスク評価に役立てることが可能である。
  • 異業種間の相互運用性:医療業界のプロトコル標準化は、他業界で使用されるデータ基盤やAPIと互換性を持つことも求められる可能性がある。たとえば、スマートシティの取り組みでは、医療データが交通データや環境データと連携することで、地域住民の健康管理や災害時の対応に役立つ可能性がある。

6.2. データ連携基盤の運用支援と標準化の適用

6.2.1 中小医療機関への支援

中小医療機関では、データ連携基盤やFHIRの導入が技術的・財政的に困難な場合がある。

  • 財政支援と技術支援:政策的に中小医療機関向けに補助金や技術サポートを提供し、標準化された基盤の導入を促進する必要がある。
  • トレーニングと専門人材育成:医療従事者に対し、FHIRやデータ連携基盤の運用に関する教育プログラムを実施する必要が生じることが予想される。

6.2.2 患者参加型データ活用

患者が自身の医療データを管理・共有できる仕組みは、データ連携基盤と標準化されたプロトコルの活用によって強化される。

  • FHIRを活用したポータルサイト:患者が自身のデータを閲覧・共有できるポータルサイトをFHIR準拠で構築することにより、自分自身でデータを利活用したり、様々なサービスで利活用されているデータの信頼性を自己確認することができる。
  • 健康アプリの統合:健康アプリがデータ連携基盤と連携することで、患者が日常的に収集するデータを医療機関と共有できるようになる。ただし、そのためには同意管理システムとの連携などほかにも考えるべきことが生じる。

6.3.2 官民連携の強化

医療関連データの利活用は、単なる市場原理に基づく利益追求だけでなく、公共の利に資する側面が強く、官民の緊密な連携が必要不可欠である。特に、政府、医療機関、IT企業が協力することで、データ連携基盤の構築がより効果的に推進される。

  • 公共データと民間データの融合公共データ(例:国民健康保険データ)と民間データ(例:ウェアラブルデバイスから得られる健康データ)を統合することで、個別化医療や地域医療の質向上、新たな医療サービスの創出が期待される。これにより、医療格差の是正や予防医療の推進といった社会的課題の解決が可能となる。
  • 標準化ガイドラインの共同策定官民が協力して標準化ガイドラインを策定することで、国内外でのデータ運用の調和が図られる。例えば、国際標準であるFHIR(Fast Healthcare Interoperability Resources)の適用を促進し、データの相互運用性を確保する取り組みが進められている。
  • 公共の利を重視した政策形成医療データの利活用は、個々の企業や団体の利益だけでなく、国民全体の健康増進という公共の目的に寄与する。日本経済新聞(2025年5月27日付)の報道によれば、政府は医療データの利活用を促すため、企業や自治体とのハブとして機能する基盤を構築し、データの一括契約を進めている。
  • セキュリティとプライバシーの確保官民連携によるデータ利活用には、個人情報保護法やGDPRなどの規制を遵守しつつ、データの安全性を確保する仕組みが求められる。匿名化技術、秘密計算、秘匿処理のような技術が持つべき役割の定義が求められる。

参考文献:


7. おわりに

国家レベルのデータ連携基盤の標準化は、医療業界において患者中心の医療、効率的な医療提供、そしてイノベーションの促進に大きく寄与する。他分野の成功事例を参考にしつつ、医療特有の課題に対応するための技術的・運用的な工夫を進めることで、持続可能な医療制度の実現が期待される。

共有

金融庁の共同データプラットフォーム最新動向と企業間データ連携の可能性

イントロダクション

金融庁が推進する「共同データプラットフォーム」は、金融機関や関連企業間での効率的なデータ共有を実現するための基盤である。本プラットフォームは、デジタル化の進展に対応し、金融業界全体の透明性と信頼性を向上させることを目的としている。

共同データプラットフォームの進捗と今後の進め方には「金融庁と日本銀行は、より質の高いモニタリングの実施と金融機関の負担軽減を図る観点から、データの一元化に取り組んできた」と記載されている。また2025年3月からは高粒度データの収集を開始する、とされている。

本稿では、2024年以降の最新動向を中心に、このプラットフォームの概要や企業間データ連携との関係性について解説する。

参考情報

共同データプラットフォームとは

データ一元化の進捗と今後の進め方(2023年)によれば、共同データプラットフォームは、金融庁と日本銀行が連携して構築を進める、より実効的・効率的なデータ収集・管理の枠組みである。このプラットフォームは以下の特徴を持つ:

  • データ収集の一元化:金融機関からの報告窓口を統一し、複数の金融当局間でデータを共有
  • 高粒度データの活用:取引単位レベルの詳細なデータを収集・分析
  • データの標準化:定義・フォーマットの標準化による一貫性と品質の確保

このプラットフォームは、金融機関の報告負担軽減と当局のモニタリング能力向上を同時に実現する、次世代の金融データ管理基盤として位置づけられている。

参考情報

最新動向(2024年以降)

2024年7月、金融庁は共同データプラットフォームの進捗と今後の計画に関する報告書を公表した。この報告書では、以下のような内容が示されている。

  • 進捗状況: データ収集・管理の新たな枠組みが整備されつつあり、データクレンジングの具体的な手法が確立。
  • 今後の計画: 金融機関間のデータ共有をさらに促進するため、新たなAPI仕様の導入を検討。

また、2024年度の金融行政方針では、共同データプラットフォームを活用したデジタル化の推進が重要な柱として位置づけられている。

参考: 2024事務年度金融行政方針

事例

(要旨) 本稿では、共同データプラットフォームの検討に向けた実証実験11に参加した地方銀行 (49 行)から収集した法人向け貸出明細等の高粒度データを用い、顧客企業の業種、製品 または地理的条件に着目し、地方銀行の気候関連リスク(移行リスク・物理的リスク)の特 徴や、それが地域毎に相違すること等を明らかにした。気候変動に関するデータや手法は発 展途上にあり、今後とも金融機関との対話への活用に向けてデータ整備及び分析の高度化に 取り組んでいく。

共同データプラットフォームにより収集された高粒度データが用いられている。

気候関連のリスク分析における高粒度データの活用方法

本分析では、共同データプラットフォームの実証実験に参加した地方銀行49行から収集した法人向け貸出明細等の高粒度データを以下のように活用している。

高粒度データの具体的内容

収集されたデータ

  • 法人向け貸出明細:個別企業への融資情報
  • 債務者明細:融資先企業の詳細情報
  • 帝国データバンクの企業データとの連携

3つの分析での活用方法

1. ファイナンスド・エミッション(FE)分析での活用

データの使用方法

  • 各融資先企業の業種別分類融資額を特定
  • 企業の売上高資金調達総額情報を活用
  • アトリビューション・ファクター(投融資額/資金調達総額)の計算に使用

具体的な計算プロセス

1
2
FE = Σ(アトリビューション・ファクターᵢ × 排出量ᵢ)
アトリビューション・ファクターᵢ = 投融資額ᵢ / 資金調達総額ᵢ

メインバンク判定

  • 各企業について、2022年3月末時点の貸出残高が最も大きい銀行をメインバンクと特定している
  • 複数の地方銀行から財務情報が取得可能な場合、貸出残高最大の銀行の財務情報を使用している

2. EV化リスク分析での活用

企業特定プロセス

  • 高粒度データから輸送用機械器具製造業に分類される企業を抽出している
  • 帝国データバンクの信用調査報告書の定性情報と連携している
  • 事業概要に「エンジン」キーワードを含む企業を機械的に抽出している

地域別分析

  • 法人貸出残高に占めるエンジン関連企業への融資割合を地域別に集計している
  • 銀行の本店所在地による地域分類を実施している

3. 物理的リスク(水災)分析での活用

住所情報の活用

  • 融資先企業の明細データを国税庁法人番号公表サイトの本店所在地住所と結合している
  • 各企業の所在地を国土交通省の洪水ハザードマップ上にマッピングしている

リスク度計算

1
リスク度 = 営業停止・停滞日数 × 融資額

地域別集計

  • 中小企業向け融資の貸出残高あたりリスク度を地方銀行の本店所在地域別に比較している
  • 市区町村別にリスク度を詳細分析を行っている

高粒度データ活用の特徴

データの粒度レベル

  • 個別企業レベルでの融資情報
  • 具体的な融資額企業属性の組み合わせ
  • 地理的な詳細情報(本社所在地まで特定)

分析の機械的処理

  • 一定の仮定に基づく機械的な試算や抽出を実施している[3]
  • 結果については相応の幅を持って解釈する必要がある[3]

データ連携の重要性

  • 金融データと外部データ(ハザードマップ、企業情報等)の結合により、従来では不可能だった詳細分析を実現している
  • 幅広いデータの活用が気候関連リスクの的確な把握に有効であることを確認している

このように、高粒度データは個別企業レベルでの詳細な分析を可能にし、地域別・業種別・リスク別の特徴を明らかにする基盤として活用されうる。

参考情報

企業間データ連携との関係性

共同データプラットフォームを一種の企業・組織間データ連携の仕組みだと考えると以下のように考察できる。

課題解決へのアプローチ

企業間でのデータ連携を円滑にするため、以下のような仕組みが導入されている。

  • データ標準化: 異なる企業間でのデータの互換性を確保。
  • 高粒度データ: 高粒度なデータを収集し、解像度が高いモニタリングを可能にする
  • 金融機関の負担軽減: 代替可能な既存計表を廃止することで負担軽減

参考: 入札公告等: データクレンジングに関する情報

参考: 共同データプラットフォームの進捗と今後の進め方

共有

Summary of Future Directions in Financial Administration

2025年1月17日に金融庁長官井藤英樹氏によって発表された、今後の金融行政の方向性について包括的に説明した資料の簡単なまとめである。

今後の金融行政の方向性 - 要約

概要

本資料は、2025年1月17日に金融庁長官井藤英樹氏によって発表された、今後の金融行政の方向性について包括的に説明したものである。

金融庁のミッション

金融庁は以下の3つの両立を通じて、企業・経済の持続的成長と安定的な資産形成等による国民の厚生の増大を目指している:

  • 金融システムの安定/金融仲介機能の発揮
  • 利用者保護/利用者利便
  • 市場の公正性・透明性/市場の活力

主要な取組分野

Ⅰ. 資産運用立国の実現

背景と目標

「資産運用立国実現プラン」(2023年12月公表)に基づき、家計の安定的な資産形成を支援し、企業価値向上の恩恵が国民に還元される好循環の実現を目指している。

主な成果

  • NISA口座数: 2,509万口座(2024年9月末)
  • NISA総買付額: 49兆円(2024年9月末)
  • 日経平均株価: 42,224円(史上最高値)
  • 東証時価総額: 996兆円(過去最高)

重点施策

  1. 家計の安定的な資産形成支援
    • NISAの抜本的拡充・恒久化
    • 金融経済教育推進機構の本格稼働
    • iDeCoの大胆な改革
  2. コーポレートガバナンス改革
    • 資本コストや株価を意識した経営の実現要請
    • 重要な会社情報の英文開示義務化
  3. 資産運用業・アセットオーナーシップ改革
    • 新興運用業者促進プログラム(日本版EMP)
    • アセットオーナー・プリンシプルの策定
    • 金融・資産運用特区の推進

Ⅱ. サステナブルファイナンスの推進

サステナビリティ開示制度

2025年3月にSSBJ基準の最終化を予定し、プライム市場上場企業を対象として段階的に導入する:

  • 2027年3月期: 時価総額3兆円以上(69社)
  • 2028年3月期、2029年3月期: 時価総額1兆円以上(179社)
  • 2029年3月期、2030年3月期: 時価総額5,000億円以上(294社)
  • 203X年3月期: プライム全企業

保証制度

サステナビリティ情報の信頼性確保のため、新たな登録制度の下で監査法人等による保証業務を導入する。

その他の取組

  • インパクト投資の基本的指針策定
  • 金融機関の気候変動対応ガイダンス
  • カーボン・クレジット取引の透明性・健全性確保

Ⅲ. デジタル技術を用いた金融サービスの変革への対応

資金決済制度の見直し

「資金決済制度等に関するワーキング・グループ」において以下を検討:

  • 資金移動業者の破綻時における利用者資金の返還方法多様化
  • クロスボーダー収納代行への規制
  • 特定信託受益権の発行見合い金の管理・運用方法柔軟化

AI利活用の促進

金融機関における健全かつ効果的なAI利活用のためのディスカッション・ペーパーを策定予定である。

Ⅳ. 金融システムの安定・信頼と質の高い金融機能の確保

金融機関の健全性

現在、我が国の金融機関は総じて充実した資本や流動性を有し、金融システムは総体として安定している。

リスク管理の強化

  • サイバーセキュリティ対策の強化
  • SNS型投資・ロマンス詐欺への対応(2024年1-6月被害額:投資詐欺約500億円、ロマンス詐欺約154億円)
  • グループ経営に対する監督態勢強化

保険市場の信頼回復

大規模な保険代理店への監督実効性向上等を進め、以下の対応を実施する:

  • 特定大規模乗合保険募集人に対する内部管理体制強化
  • 保険仲立人の活用促進
  • 企業内代理店に関する規制の再構築

Ⅴ. 金融行政の進化・深化

データ活用の高度化

  • 日本銀行と連携した共同データプラットフォームの段階的運用開始
  • 職員によるデータ分析取組みの促進
  • アカデミアとの連携強化

組織力向上

  • マネジメント宣言による透明性向上
  • 360度評価のグループ長以上への拡大
  • 柔軟かつ合理的・効率的に働ける環境整備

まとめ

金融庁は、「賃上げと投資が牽引する成長型経済」の実現に向けて、資産運用立国と投資立国の両輪で取り組みを進めている。デジタル技術の活用、サステナブルファイナンスの推進、金融システムの安定確保を通じて、国民の厚生増大と持続的な経済成長を目指している。

共有

金融庁の2025年以降の動向と重点施策

概要

金融庁は2025年以降、「資産運用立国」の実現を最重要課題として位置づけ、包括的な金融行政改革を推進している。2025/1/17の「金曜例会」にて出された「今後の金融行政の方向性」では、以下の重点施策が掲げられている:

・資産運用立国の実現 ・サステナブルファイナンスの推進 ・デジタル技術を用いた金融サービスの変革への対応 ・金融システムの安定・信頼と質の高い金融機能の確保(サイバーセキュリティへの対応強化) ・金融行政の進化・深化(日銀と連携した共同データプラットフォームの段階的運用開始、2025/3から本格的なデータ収集を開始)

この方針を実現するため、2025年7月に新設される資産運用課を中核として、資産運用業を金融業の新たな柱に育成する。また、国際金融センターとしての競争力強化を通じて、持続可能で包摂的な経済成長への貢献を目指している。

主要なポイント

1. 組織体制の強化と資産運用立国の実現

  • 資産運用課の新設(2025年7月予定)

    金融庁監督局内に「資産運用課」を新設し、銀行業・証券業・保険業と並ぶ第4の監督担当課として位置づける。これは2018年7月の組織再編以来6年ぶりの課新設となる。

  • 主旨

  • **資産運用立国の実現に向けた取組についてでは、以下のような施策が挙げられている**

    • 大手金融グループ等の運用力向上プラン
      • 16の金融グループ等が以下の3つの観点からプランを策定・公表している
        • 経営戦略上の位置付け: 資産運用業を成長・注力分野として、グループ内の他の事業・機能と並ぶ柱として位置付け
        • 運用力向上: オルタナティブ分野・アクティブ運用の拡充、外部運用会社との提携、人材確保・育成
        • ガバナンス改善・体制強化: プロダクトガバナンスの強化、経営トップ選任プロセスの透明化
    • 新興運用業者促進プログラム(日本版EMP)
      • 新興運用業者のシードマネー獲得を支援するための官民連携の取組
        • 金融機関に新興運用業者の積極的活用を要請
        • エントリーリストの提供
        • ミドル・バックオフィス業務の外部委託による規制緩和*
    • 投資運用業者の参入促進
      • ミドル・バックオフィス業務の委託に係る制度整備として、以下の改正が行われた
        • 任意の登録制度創設: ミドル・バックオフィス業務を受託する事業者の登録制度
        • 登録要件の緩和: 人的体制整備要件の緩和、資本金要件の引下げ(5000万円→1000万円)
        • 運用権限の全部委託: ファンドの運営機能(企画・立案)に特化し、運用(投資実行)を全部委託することが可能
    • アセットオーナー・プリンシプル
      • 2024年8月28日に公表された、アセットオーナーに求められる5つの原則。
        • 原則1: 運用目的、運用目標及び運用方針の策定
        • 原則2: 専門的知見に基づく体制整備
        • 原則3: 適切な運用方法の選択とリスク管理
        • 原則4: ステークホルダーへの情報提供(「見える化」)
        • 原則5: スチュワードシップ活動の実施

2. サステナブルファイナンスの推進

  • 企業開示の充実と信頼性確保

    ESG評価・データ提供機関に関する行動規範の整備や、気候変動対応に向けた企業開示の充実を進める 2

  • 金融機関による脱炭素支援

    金融機関による脱炭素に向けた企業支援等の推進、インパクト投資の実践促進を図る 2 [4]。

  • トランジションファイナンスの促進

    持続可能な社会の実現に向けた移行期間における金融支援の枠組みを整備する 2

3. 金融デジタル化への対応

  • フィンテック・Web3への対応

    フィンテック支援室の機能強化を通じて、Web3を含む新たなテクノロジーの動向を注視し、適切な規制・監督の枠組みを整備する 3

  • デジタル・分散型金融(DeFi)への対応

    急速に発展するデジタル金融サービスに対する適切な監督体制の構築を進める 3

4. 金融行政の高度化

  • データ活用の高度化

    AI・ブロックチェーン技術の活用を通じて、データ活用の高度化を推進する

    「データ活用の高度化などの金融行政の高度化」の中に、「共同データプラットフォーム(共同DP)」が挙げられている。(p.51)★

  • 政策発信力の強化

    国内外に対する政策発信力の強化、若手職員をはじめとする職員の能力・資質の向上を図る 1

  • 金融犯罪対策の強化

    マネーロンダリング・テロ資金供与対策、サイバーセキュリティ対策を強化し、金融システムの安定を確保する。

5. 国際連携の強化

予算・体制

  • 2025年度予算: 239億円(前年度比+5億円)
  • 新規定員: 資産運用課新設に伴う専門人材の配置
  • 重点投資分野: デジタル化対応、国際連携、人材育成 1 3

関連キーワード

  • 資産運用立国
  • NISA恒久化
  • サステナブルファイナンス
  • ESG投資
  • 金融DX
  • フィンテック
  • Web3
  • デジタルマネー
  • 気候変動対応
  • 金融行政の高度化
  • 国際連携
  • マネロン規制
  • サイバーセキュリティ

今後の展望

金融庁は2025年以降、これらの包括的な施策を通じて、日本の金融システムの安定と国際競争力の向上を目指している。特に「資産運用立国」の実現により、国民の安定的な資産形成を支援し、経済全体の生産性及び企業価値の向上を後押しする方針である 3。また、急速に変化する金融環境に柔軟に対応するため、継続的な政策の見直しと関係者との対話を重視していく 1 2

参考URL

  1. 金融庁公式サイト - 2024事務年度金融行政方針
  2. 金融庁 - サステナブルファイナンスの取組み
  3. 新しい資本主義実現会議 - 資産運用立国分科会
  4. ニッキンONLINE - 金融庁、7月に「資産運用課」新設
  5. 日本経済新聞 - 金融庁、資産運用課を新設
共有

Raspberry Piで画像編集ソフトを使おう

はじめに

Raspberry Piは小型で手軽なコンピューターであるが、画像編集作業も十分にこなすことができる。本記事では、Raspberry Pi OSで利用可能な代表的な画像編集ソフトウェアを紹介する。

1. GIMP (GNU Image Manipulation Program)

GIMPは、オープンソースの画像編集ソフトウェアであり、Photoshopに似た機能を提供している。

インストール方法

1
2
sudo apt update
sudo apt install gimp

主な機能

  • レイヤー操作
  • フィルター効果
  • 色調補正
  • 画像サイズ変更

2. ImageMagick

コマンドラインベースの強力な画像処理ツールである。バッチ処理に特に優れている。

インストール方法

1
sudo apt install imagemagick

基本的な使用例

1
2
3
4
5
6
7
8
# 画像サイズの変更
convert input.jpg -resize 800x600 output.jpg

# フォーマット変換
convert image.png image.jpg

# 画像の回転
convert input.jpg -rotate 90 output.jpg

3. Fotoxx

軽量で使いやすい画像編集ソフトウェアである。

インストール方法

1
sudo apt install fotoxx

主な機能

  • RAW画像の編集
  • HDR合成
  • パノラマ作成
  • 赤目除去

4. Inkscape

ベクター画像の編集に特化したソフトウェアである。

インストール方法

1
sudo apt install inkscape

主な用途

  • ロゴデザイン
  • イラスト作成
  • 図形描画
  • テキストアート

5. Shotwell

写真管理と基本的な編集機能を備えたソフトウェアである。写真のインポート、整理、簡単な編集が可能。

インストール方法

1
sudo apt install shotwell

主な機能

  • 写真の一括インポートと管理
  • 基本的な画像編集(明るさ、コントラスト調整など)
  • 写真のタグ付けと整理
  • RAWファイルのサポート
  • SNSへの直接共有機能

まとめ

Raspberry Piでも、目的に応じて様々な画像編集ソフトウェアを利用することができる。用途に合わせて適切なツールを選択することで、効率的な画像編集作業が可能となる。

参考リンク

共有

Raspberry Pi OSでCapslockをCTRLにする

はじめに

Raspberry Pi OSでCapslockキーをCtrlキーとして使用する方法を説明する。

環境

  • Raspberry Pi OS (64-bit)
  • Raspberry Pi 5

設定手順

Raspberry Pi OS(RaspberryPi5)で、CTRLキーとCaps Lockを入れ替える方法 (Swap ctrl and capslock keys) を参考にした。本環境では日本語キーボードではなく、USキーボードを使用しているため、設定ファイルが異なる。

/usr/share/X11/xkb/symbols/us を編集する。

参考設定の通り、xkb_symbols "basic" の中に

1
2
key <CAPS> {        [ Control_L                     ]       };
modifier_map Control { <CAPS> };

を追記した。

その後、リブートする。

参考リンク

Raspberry Pi OS(RaspberryPi5)で、CTRLキーとCaps Lockを入れ替える方法 (Swap ctrl and capslock keys)

共有

GitHub Actionsを使ったレポジトリの同期(一方向)

動機

これまで組織名を設けずにGitHubを使っていた。しかし、Notion AIのConnect機能を利用して、GitHub上のレポジトリ群を読み取らせようとしたところ、組織下のレポジトリしか参照できないようだった。そこで、新たに組織を作成し、元のレポジトリから新しく作成した組織下のレポジトリに同期するようにした。

なお、この手順は、同期先のレポジトリがもともと存在しないことを想定して書いてある。

手順: 同期先リポジトリの初期設定と同期プロセス

1. 同期先リポジトリを新規作成

GitHub上で同期先リポジトリを作成する(例: 組織名/リポジトリ名)。

  • リポジトリの設定:
    • 空のリポジトリとして作成(README.md.gitignore は追加しない)。
    • 必要に応じて「Write Access」のあるユーザーやDeploy Keyを設定。

2. ローカル環境での初期設定

ローカル環境を使って、同期元リポジトリから同期先リポジトリへ初期データを移行する。

(1) 同期先リポジトリをクローン

ローカル環境に同期先リポジトリをクローンする。

1
2
git clone git@github.com:組織名/リポジトリ名.git
cd リポジトリ名

(2) masterブランチを作成

新規作成したリポジトリにはブランチが存在しないため、master ブランチを作成する。

1
git checkout -b master

(3) 同期元リポジトリをリモートとして追加

同期元リポジトリ(例: ユーザー名/リポジトリ名)をリモートとして追加する。

1
git remote add source git@github.com:ユーザー名/リポジトリ名.git

(4) 同期元リポジトリをpull

同期元リポジトリからデータを取得する。

1
git pull source master

(5) 同期先リポジトリにpush

同期先リポジトリにデータをプッシュする。

1
git push origin master

3. SSHキーの生成と登録

GitHub Actionsが同期先リポジトリにアクセスできるようにするため、SSHキーを設定する。

(1) SSHキーの生成

以下のコマンドを実行し、新しいSSHキーを生成する(既存のSSHキーを使用する場合はこの手順を省略可能)。

1
ssh-keygen -t ed25519 -C "your-email@example.com"
  • 入力プロンプト:
    • 「Enter file in which to save the key」では、デフォルトの ~/.ssh/id_ed25519 を使用する場合、そのままEnterを押す。
    • 「Enter passphrase」では、必要に応じてパスフレーズを設定する(空でも可)。
  • 生成されるファイル:
    • 秘密鍵: ~/.ssh/id_ed25519
    • 公開鍵: ~/.ssh/id_ed25519.pub

(2) 公開鍵を「Deploy Keys」に登録

生成された公開鍵(id_ed25519.pub)を同期先リポジトリの「Deploy Keys」に追加する。

  • 手順:
    • GitHubで同期先リポジトリを開く。
    • 「Settings」 > 「Deploy keys」 に移動する。
    • 「Add deploy key」 をクリックする。
    • 以下の情報を入力する:
      • Title: 任意の名前(例: GitHub Actions Key)。
      • Key: id_ed25519.pub の内容をコピーして貼り付ける。
      • Allow write access: チェックを入れる(書き込み権限を付与するため)。
    • 「Add key」 をクリックして登録を完了する。

(3) 秘密鍵をSecretsに登録

生成された秘密鍵(id_ed25519)を同期元リポジトリのSecretsに登録する。

  • 手順:
    • GitHubで同期元リポジトリを開く。
    • 「Settings」 > 「Secrets and variables」 > 「Actions」 に移動する。
    • 「New repository secret」 をクリックする。
    • 以下の情報を入力する:
      • Name: SYNC_SSH_KEY
      • Value: id_ed25519 の内容をコピーして貼り付ける。
    • 「Add secret」 をクリックして登録を完了する。

4. GitHub Actionsを設定

リポジトリの初期化が完了したら、GitHub Actionsを設定して自動同期を有効にする。

(1) GitHub Actionsワークフローの作成

以下のワークフローを .github/workflows/sync.yml に保存する。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
name: Sync Repository

on:
push:
branches:
- master

jobs:
sync:
runs-on: ubuntu-latest

steps:
# ソースリポジトリをチェックアウト
- name: Checkout source repository
uses: actions/checkout@v3
with:
repository: ユーザー名/リポジトリ名
token: ${{ secrets.GITHUB_TOKEN }}
ref: master

# ターゲットリポジトリにプッシュ
- name: Push to target repository
env:
TARGET_REPO: git@github.com:組織名/リポジトリ名.git
SSH_PRIVATE_KEY: ${{ secrets.SYNC_SSH_KEY }}
run: |
# SSHキーの設定
mkdir -p ~/.ssh
echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
ssh-keyscan -H github.com >> ~/.ssh/known_hosts

# ターゲットリポジトリをリモートとして追加
git remote add target "$TARGET_REPO"

# ターゲットリポジトリにプッシュ
git fetch --unshallow
git push --force target master

5. GitHub Actionsの実行確認

  1. GitHub Actionsが正常に動作するか確認するため、同期元リポジトリに変更を加える。
  2. 同期元リポジトリのmasterブランチに変更をプッシュする。
  3. 同期先リポジトリでGitHub Actionsがトリガーされ、変更が同期されていることを確認する。

6. 同期先のGitHub Actionsの無効化

GitHub Actionsの設定ファイルは、.github/workflows以下に保存されるが、このファイルも同期され、同期先のGitHub Actionsも動作してしまう。

これを防ぐため、以下の手順で同期先リポジトリのGitHub Actionsを無効化する:

  • 同期先リポジトリのページを開く
  • 「Actions」タブをクリック
  • 左サイドバーの「Actions」にある当該アクションを選択
  • 右の方にある三点リーダーから「Disable workflow」を選ぶ。

補足: トラブルシューティング

エラー: Permission denied (publickey)

SSHキーが正しく設定されていない可能性がある。以下を再確認すること:

  • SYNC_SSH_KEY に登録した秘密鍵が正しいか。
  • 公開鍵が同期先リポジトリの「Deploy Keys」に正しく登録されているか。
  • 公開鍵に書き込み権限(Write Access)が付与されているか。

エラー: remote unpack failed: index-pack failed

同期元リポジトリが大きすぎる場合に発生する。リポジトリサイズを縮小する方法については、こちらの手順を参照のこと。

エラー: git@github.com: Permission denied (publickey)

SSH接続が正しく設定されていない可能性がある。以下を確認すること:

  • SSHキーペアが正しく生成されているか。
  • GitHub Actionsのワークフローで正しいSSHキーが使用されているか。
  • ~/.ssh/known_hosts ファイルが正しく設定されているか。

まとめ

  1. 同期先リポジトリを新規作成した場合、ローカル環境で初期設定を行う。
  2. 初期設定後、GitHub Actionsを設定して自動同期を有効にする。
  3. 必要に応じてトラブルシューティングを実施する。

これにより、同期先リポジトリの初期化とGitHub Actionsを用いた同期がスムーズに行えるようになる。

共有

Recent activity about Tuple Space

メモ

とあることをきっかけに、Tuple Spaceに関して今一度整理しておきたくて検索した。 Twenty years of coordination technologies が2020年ころまでのCordiantion Technologyの歴史を振り返っており大変参考になった。

Twenty years of coordination technologiesの概要

長いのでざっくり要約すると…

概要: この論文は、COORDINATIONカンファレンスの20年の歴史を振り返り、調整技術(Coordination Technologies)の発展と現状を分析した包括的なレビュー論文。 IoTなどの影響で、システム間の相互作用の複雑さが増していることから調整技術の重要性を強調。 サクセスストーリーや制限を明確にする。

なお、ここでいう調整技術とは、Coordination Models and Languagesに基づき、「複数の異種コンポーネントを統合する手段を提供する」ことを目指す技術を指すことにする。

全体的なトレンド

初期:基礎的なモデルと実験的な実装 中期:モバイル環境やセキュリティへの対応 後期:IoTや分散システムへの実践的な適用

1996-2000年(初期)

Linda モデルをベースとした多くの技術が登場

主な技術: - ACLT (1996) - 後のTuCSoNの基礎となる - Manifold (1996) - 後のReoの基礎となる - Moses (2000) - 法に基づく相互作用(LGI)モデルの実装 - Piccola (2000) - コンポジション言語

2001-2010年

より専門化・多様化した技術の出現

主な技術: - Reo (2002) - チャネルベースの調整モデル - O'Klaim (2004) - モバイルコード向けの調整 - Limone (2004) - モバイルエージェント向けの軽量調整 - CRIME (2007) - 論理ベースの調整 - CiAN (2008) - MANETsのためのワークフロー管理

2011-2018年

より実践的で特定領域に特化した技術の登場

主な技術: - LINC (2015) - IoT向けの商用調整技術 - RepliKlaim (2015) - データレプリケーション管理 - Logic Fragments (2015) - 論理推論ベースの調整 - TuCSoN - 継続的な発展と実用化

論文執筆辞典(2020年)現在の課題

  • 産業界での採用が限定的
  • 開発・デプロイメントツールの不足
  • メインストリームの開発言語・プラットフォームとの統合の必要性
  • 実用的なモニタリング・デバッグツールの不足

貢献

理論的貢献: - 形式的なモデリング言語の発展 - 検証技術の進歩 - 新しい調整パラダイムの提案

実践的な応用: - 分散システムの設計パターン - ミドルウェアソリューション - クラウドサービスの調整メカニズム

将来の展望: - AIと機械学習を活用した適応型調整メカニズム - ブロックチェーンベースの分散調整 - エッジコンピューティングにおける調整課題 - 大規模分散システムのための新しい調整モデル

参考文献: - https://www.researchgate.net/publication/339464058_Twenty_years_of_coordination_technologies_COORDINATION_contribution_to_the_state_of_art - https://www.researchgate.net/publication/325388738_Twenty_Years_of_Coordination_Technologies_State-of-the-Art_and_Perspectives - https://core.ac.uk/download/pdf/196287252.pdf - https://scispace.com/journals/the-journal-of-logic-and-algebraic-programming-1ay8iggr/2020

Tuple Spaceに類似した技術

概要

Tuple Spaceに類似した技術は、分散システムにおけるデータ共有と通信を実現するための抽象化モデルとして発展してた。Linda modelを起点として、クラウドコンピューティング、IoT、マイクロサービスアーキテクチャなどの現代的なコンテキストで進化している。これらの技術は共通して、非同期通信、データの永続性、空間的・時間的な分離を特徴としている。 ここでは直接の派生とは言えないものも列挙してみる。

主要なポイント

類似技術の分類

  • メッセージキューイングシステム
    • Apache Kafka
    • RabbitMQ
    • Amazon SQS
    • Redis Pub/Sub
  • 分散キーバリューストア
    • Apache Cassandra
    • Redis
    • Hazelcast
    • Apache Ignite
  • 分散共有メモリシステム
    • JavaSpaces
    • GigaSpaces
    • TSpaces (IBM)
    • Lime (Mobile Tuple Spaces)
  • Triple Space
    • TripCom (Triple Space Communication)
    • Web Service Execution Environment (WSMX)との統合

共通と思われる特徴

  • 非同期通信モデル
  • データの永続性サポート(実装の途中から対応したものもある)
  • 分散トランザクション処理(厳密にはトランザクション管理されていないものもある。あるいは後付けでトランザクション管理の機能が追加されたものもある)
  • スケーラビリティ
  • 耐障害性

技術的な差異を考えるうえでの観点の例

  • データモデル(構造化vs非構造化)
  • 一貫性モデル(強一貫性vs結果一貫性)
  • スケーリング方式(水平vs垂直)
  • 実装アプローチ(中央集権型vs分散型)

関連検索に用いるキーワード

  • Linda Model
  • Distributed Coordination
  • Shared Memory Systems
  • Message-Oriented Middleware
  • Distributed Hash Tables
  • Space-Based Architecture
  • Content-Based Publish/Subscribe
  • Distributed Data Structures

参考文献・URL

(作業途中。とりあえず簡単な例を記載しているが網羅性を高める必要あり)

学術論文

  1. "Coordination Models and Languages" (2001) https://link.springer.com/chapter/10.1007/3-540-45587-6_3

  2. "A Survey of Tuple Space Implementations" (1998) https://dl.acm.org/doi/10.1145/292834.292836

  3. "Space-Based Computing and Reliable Distributed Systems" (2019) https://ieeexplore.ieee.org/document/8731537

技術記事・ドキュメント

  1. Apache Kafka Documentation https://kafka.apache.org/documentation/

  2. JavaSpaces Principles, Patterns, and Practice https://www.oracle.com/technical-resources/articles/javase/javaspaces.html

  3. GigaSpaces Technical Documentation https://docs.gigaspaces.com/latest/overview/index.html

研究プロジェクト

  1. LIME Project (Mobile Tuple Spaces) http://lime.sourceforge.net/

  2. T-Spaces Project (IBM Research) https://researcher.watson.ibm.com/researcher/view_group.php?id=128

本分野の主な応用分野

  • クラウドコンピューティング
  • IoTシステム
  • マイクロサービスアーキテクチャ
  • 分散データ処理
  • リアルタイムアナリティクス
  • エッジコンピューティング
  • データスペース ※きっと…という期待を込めて。

今後の話の広がりの方向性の例

  • AIや機械学習システムとの統合
  • ブロックチェーン技術との関係性整理と統合、あるいは分担
  • エッジコンピューティングでの活用
  • 次世代ネットワーク通信での応用
  • 量子コンピューティングとの関係性、応用
  • データスペースのモデル化

参考

共有