dotとは何か ― 常時稼働AIエージェントでFortran・Python・Juliaの開発はどう変わるのか
2026年10月14日時点のOpenAI公式情報を基に整理しました。機能、提供プラン、利用上限、設定画面は今後変更される可能性があります。後半の開発例は、公式に保証された連携構成ではなく、実際に組み立てる際の提案です。
はじめに
数値シミュレーションの開発では、ソースコードを書くだけで作業が終わるわけではありません。計算条件を揃え、テストデータを準備し、計算結果を比較し、不具合を調べ、修正内容を記録する必要があります。
特にFortranで計算コアを作り、Pythonで前後処理やWeb APIを構築し、Juliaでも同じ計算を実装して比較するような構成では、開発環境と検証手順の管理が重要になります。
OpenAIが2026年9月29日に発表した**dot（ドット）**は、こうした複数の作業を継続的に管理するためのAIエージェントです。通常のChatGPTが「質問に答える」「その場で一つの仕事を進める」ことを中心にしているのに対し、dotは目標を与えておくと、会話の合間にも作業を進め、結果や判断が必要な事項を知らせることを目指しています。
本記事では、dotの基本的な仕組みから、PCに直接インストールしたUbuntu 24.04 LTS（ネイティブ環境）、Docker Engine、GitHub、Fortran 2018、Python、Juliaを組み合わせた開発への応用まで整理します。仮想マシンやWSL2は前提としません。Ubuntu Desktopと、画面を持たないUbuntu Serverの場合も区別します。
1. dotとは
OpenAIの説明によると、dotは常時稼働型（always-on）のAIエージェントです。GPT-6 Astraを基盤とし、専用のクラウドコンピューターを持ち、許可されたアプリや各種の作業環境を使って、長期的な目標の達成を支援します。
主な特徴は次のとおりです。
- 目標や作業方針を引き継ぎ、会話と会話の間も継続的に仕事を進められます。
- 専用のクラウドコンピューターを使用できます。
- アプリの接続を許可すると、必要な情報を確認したり、許可された操作を行ったりできます。
- Codexのクラウド環境や、明示的に接続したローカルPCを利用できます。
- 定期的な確認や通知を設定できます。
- 作業内容の確認、方針変更、一時停止、重要な操作への承認ができます。
ただし、「24時間使える」という説明は、あらゆる計算処理を時間や回数の制限なく実行できるという意味ではありません。高度な作業やCodex・Workに委ねるタスクには、利用枠や個別の実行条件があります。また、dotが常に自分のPC上で動いているわけでもありません。
従来のChatGPTとの違い
| 比較項目 | ChatGPT（Chat） | ChatGPT Work | Codex | dot |
|---|---|---|---|---|
| 主な役割 | 質問・相談・説明 | 複数工程の調査や成果物作成 | ソフトウェア開発 | 長期目標を管理する継続型エージェント |
| 得意な作業 | 知識整理、設計相談 | 調査、資料作成、複数ステップの作業 | コード修正、テスト、レビュー | 作業の継続、状況把握、タスクの委任 |
| コードの実行 | 利用可能なツールの範囲内 | 許可された実行環境 | 対応する開発環境 | 自分のクラウドPCや委任先の環境を利用 |
| 定期作業 | 機能・設定による | スケジュール実行に対応 | 開発タスク中心 | 定期タスクと先回りの情報確認に対応 |
| 人の役割 | 質問して結果を確認 | 作業の指示とレビュー | 差分とテストのレビュー | 目標・権限を定め、重要な判断を行う |
dotはCodexの代替ではありません。 dotが仕事全体の目的や継続性を担当し、プログラミング作業そのものをCodexに依頼する、という役割分担が考えられます。Workにも継続・定期作業の機能があるため、両者の差を「dotだけが自動実行できる」と理解しない方が正確です。
2. dotはどのように作業するのか
典型的な開発作業は、以下のような流れになります。
この図は実際の役割分担を考えるための概念図です。実線は想定する処理の流れ、破線は事前に可否と権限を確認する部分です。dotに目標を渡しただけで、UbuntuのファイルやDockerソケットへのアクセス権限が自動的に付与されるわけではありません。
2.1 専用クラウドコンピューター
dotには専用のクラウドPCがあります。ここでブラウザー操作やファイルを使った処理を進められます。ただし、必要なソフトウェアが最初からすべて入っているとは限りません。
たとえばFortranやJuliaの計算をクラウド側で行うなら、実行環境にgfortranやjuliaが用意されているかを確認する必要があります。Pythonも必要なライブラリのバージョンや利用可能な計算資源を確認します。GPUの有無や性能も自動的に保証されません。
2.2 Codexとの連携
公式ヘルプによれば、dotはCodexのクラウド環境にタスクを作成できます。ただし、Codex側で使用するクラウド環境をあらかじめ作成しておく必要があります。
リポジトリとテスト環境を用意しておけば、「不具合を調査する → ブランチ上で修正する → テストする → 差分をレビューに回す」という使い方が考えられます。プルリクエストの作成や更新が可能かは、接続先の権限と実際の環境に依存します。
2.3 Ubuntu 24.04のローカル環境との連携
OpenAIはUbuntu 24.04 LTSに対応するChatGPTデスクトップアプリのプレビュー版を公開しています。Ubuntu Desktopであれば、公式の.debパッケージから導入できます。ChatGPT、Work、Codexとローカルの開発ファイルを組み合わせるための入口になります。
ただし、機能ごとにLinux対応状況は異なります。2026年10月14日時点では、Linuxプレビュー版のComputer Use（他のGUIアプリを直接操作する機能）は未対応です。また、dotのローカルコンピューター連携は別途の接続・許可操作が必要です。Linuxアプリがインストールできることと、dotからUbuntu上の全操作を自動実行できることは同義ではありません。
Ubuntuでの運用は、次の二つに分けて考えると明確になります。
| Ubuntuの種類 | dotの操作・連携方針 | 備考 |
|---|---|---|
| Ubuntu 24.04 Desktop | 対応したChatGPT Linuxアプリを利用し、ローカル操作の可否を機能ごとに確認 | Linux版はプレビュー。Computer Useは未対応 |
| Ubuntu 24.04 Server（GUIなし） | ブラウザー上のdot、Codexクラウド環境、GitHub/CIを中心にする | Linuxデスクトップアプリをサーバーで起動する前提にしない |
サーバー上でテストを実行したい場合は、Ubuntu 24.04にGitHub Actions Self-hosted Runnerを設置し、許可されたワークフローだけを実行する構成が一案です。ただし、dotがそのランナーを直接操作するのではなく、GitHub上の変更・ワークフローを介した間接的な連携です。GitHubの権限、Runnerのセキュリティ、秘密情報の取扱いは別途設計します。
公式情報： ChatGPT desktop app for Linux、dotスタートガイド
3. Fortran・Python・Juliaを組み合わせるメリット
計算プログラムを複数言語で構成している場合、dotにすべてのプログラムを直接書かせるより、共通の仕様とテスト基準を管理させる方が有効です。
| 言語・技術 | 主な担当 | dotに任せる作業の例 | 人が特に確認する点 |
|---|---|---|---|
| Fortran 2018 | 数値ソルバー | コード調査、コンパイル、回帰テスト、性能測定 | 保存則、境界条件、計算精度 |
| Python | 入出力、FastAPI、前後処理、図化 | pytest、ruff、mypy、APIテスト、データ処理 | データ型、座標系、I/O整合性 |
| Julia | 数値モデルの再実装、比較、最適化 | Pkg.test、数値比較、実行時間測定 | 離散化条件、精度、アルゴリズムの同等性 |
| Docker Engine / Compose | 実行環境の統一 | 設定確認、イメージ構築、テストの実行 | バージョン、マウント、権限、再現性 |
| GitHub Actions | CI/CD | 失敗ジョブの調査、ログ整理、修正案 | PASSの根拠、権限、デプロイ判断 |
3.1 Fortran 2018の開発
Fortranは数値計算の中心部分に適しています。特に既存ソルバーを保守する際には、新しい機能を加える前に、現行版の計算結果と一致するかを確認することが重要です。
例として、dotに次の仕事を依頼できます。
対象はFortran 2018で記述された河川1Dソルバーです。
作業用ブランチだけを使用して、計算結果が不安定になる原因を調査してください。
まずテスト条件、コンパイラー、境界条件、型の精度を記録してください。
最小再現ケースを作成し、修正前後の水位・流量・水収支を比較してください。
テストを実行していない場合はPASSと書かないでください。
ソース変更、結果、残る課題を報告し、mainへのマージは行わないでください。
数値計算の場合、コンパイル成功だけでは動作確認になりません。たとえば、計算領域全体の水収支残差は次のように確認できます。
R_V = (V_{\mathrm{end}} - V_{\mathrm{start}})
-\int_{t_0}^{t_1}
\left(
Q_{\mathrm{in}} - Q_{\mathrm{out}} + Q_{\mathrm{source}}
\right)\,dt
ここでの流入・流出・内部ソース項の符号規約や境界での計上方法は、対象ソルバーの定義に合わせる必要があります。水収支残差が小さいことだけで解が正しいとは判断せず、既知解や観測との整合性も確認します。
SIMD、OpenMP、MPIによる高速化を依頼する場合も、高速化前と同一条件で比較し、精度を損なっていないかの確認が必要です。
3.2 Pythonの開発
Pythonには、ソルバーの前後処理、FastAPIのWeb API、NumPyによる配列処理、pandasでのデータ整理、matplotlibでのグラフ作成などを担当させます。
dotに適した依頼例は、次のとおりです。
PythonのFastAPIと解析ツールを確認してください。
まず現在のAPI仕様、依存ライブラリ、テスト方法を調べてください。
ruff、mypy、pytestを実行し、失敗した箇所を分類してください。
Fortranから出力したCSVの列名・単位・欠損値を検証し、
計算結果の可視化まで含む小さな回帰テストを追加してください。
変更内容はdiffで示し、テストログと実行環境を報告してください。
ここでも、ruffやpytestが利用できる環境はあらかじめ構築しておく必要があります。パッケージ追加や環境変更を伴う操作は、承認ルールに従います。
3.3 Juliaの開発
Juliaは数値計算を高水準のコードで記述しながら、高速化やモデル比較を進めたい場面に適しています。Fortran実装を参照解の一つとして、同じ入力と境界条件を使い、Julia実装との差を整理する運用が考えられます。
Julia 1.13系で作成した数値計算プロジェクトを確認してください。
Fortran版と同じ格子、タイムステップ、初期条件、境界条件を用います。
両実装の数値出力を比較し、最大絶対誤差、RMSE、水収支残差を出してください。
Float32/Float64の違い、計算順序、最適化オプションによる差は区別してください。
Pkg.testを実行し、未実行項目と失敗項目を明示してください。
性能比較は初回コンパイル/JITの影響を分けて測定してください。
数値比較では、言語だけでなくアルゴリズム、浮動小数点精度、離散化、収束条件、入出力の意味が一致していることが前提になります。JuliaとFortranで結果が違っても、その差が直ちにプログラムの不具合とは限りません。
4. 推奨する開発環境：Ubuntu 24.04ネイティブ
本記事では、Ubuntu 24.04 LTSをPCへ直接インストールした環境を想定します。OS上でDocker Engine / Docker Composeを稼働させ、そのコンテナ内でFortran・Python・Juliaのテストを実行します。Docker Desktopは使用しません。
上の図のGitHub ActionsからSelf-hosted Runnerへの連携は、利用者がRunnerを登録し、明示的にワークフローを構成した場合のみ成立します。dotのローカルアクセス機能とCI実行を混同しないようにします。
4.1 Ubuntu 24.04環境を確認する
Ubuntu上のターミナルで次のコマンドを実行し、OS、CPU、開発ツールの有無を調べます。
# Ubuntu 24.04を直接インストールしたPCで実行
cat /etc/os-release
uname -m
uname -r
# インストール済みコマンドを調査（未導入のものは表示されません）
for name in git docker gfortran fpm python3 julia; do
command -v "$name" || echo "未導入: $name"
done
# 以下は存在するツールだけを実行してください
docker --version
docker compose version
gfortran --version
python3 --version
julia --version
/etc/os-releaseのVERSION_IDが24.04であることを確認します。dockerの存在だけではDockerデーモンの稼働確認にならないため、必要に応じてdocker infoやdocker compose psで追加確認します。GPU計算を行う場合は、ドライバー、コンテナのGPUアクセス、対象ライブラリの対応を別に調べます。
4.2 Ubuntu DesktopにChatGPTアプリを導入する場合
公式ガイドでは、Ubuntu 24.04 Desktop向けのプレビュー版パッケージが配布されています。Ubuntu Server（GUIなし）では、この節の操作は不要です。
- Linux版の公式インストールガイドにアクセスします。
- CPUアーキテクチャを
uname -mで確認し、x64またはARM64の.debをダウンロードします。 - ダウンロードしたファイル名に合わせ、Ubuntuのターミナルからインストールします。
# 公式ページからx64版の .deb を取得済みの場合の例
cd ~/Downloads
sudo apt install ./chatgpt_amd64.deb
# インストール後（GUIセッションから）
chatgpt
ARM64の場合はパッケージ名が異なります。提供版や制限事項は更新される可能性があります。Linux版ではComputer Useが未対応のため、dotによるGUIの遠隔操作を前提にした自動化は設計しません。ローカルのコマンドやファイルへのアクセスも、権限と動作可否の確認を行ってから利用します。
4.3 ソースコードの管理例
一例として、次のようなリポジトリに分けておくと作業単位が明確になります。
simulation-lab/
├── fortran/
│ ├── fpm.toml
│ ├── src/
│ └── test/
├── python/
│ ├── pyproject.toml
│ ├── src/
│ └── tests/
├── julia/
│ ├── Project.toml
│ ├── src/
│ └── test/
├── docker/
├── scripts/
│ ├── check_fortran.sh
│ ├── check_python.sh
│ └── check_julia.sh
├── testdata/
├── docs/
└── .github/workflows/
このディレクトリ構成は設計例であり、ダウンロード可能な動作確認済みのソース一式を示しているわけではありません。既存のプロジェクトに合わせて調整してください。Docker実行用ユーザーや出力先の所有権も、初期段階で決めておきます。
4.4 言語別のテストコマンド例
テスト用プロジェクトが準備されている場合、次のようなコマンドが候補になります。
Fortran・Python・Juliaのテストコマンドを開く
# Fortran: fpm.toml があり、fpm が使える場合
cd fortran
fpm test
cd ..
# Python: pyproject.toml とテスト一式がある場合
cd python
python3 -m pytest
python3 -m ruff check .
python3 -m mypy .
cd ..
# Julia: Project.toml と test/runtests.jl が整備されている場合
julia --project=julia -e 'using Pkg; Pkg.instantiate(); Pkg.test()'
# Composeファイルがある場合
# docker compose -f docker/compose.yaml config --quiet
これらは実行手順の候補です。本記事の作成時に実際のUbuntu PCやDocker環境に対して実行した結果ではありません。依存関係が未導入であればコマンドは失敗します。最初に環境構築方法とテスト条件を固定し、結果ログを保存する必要があります。
5. dotを中心にした開発の進め方
おすすめは、最初から大きなシステム全体を任せず、段階を分ける方法です。
| 段階 | 目的 | 成果物 | 完了判断 |
|---|---|---|---|
| Step 1 | ソース・環境の棚卸し | 構成一覧、未確認事項 | 実在するファイルとツールを確認した |
| Step 2 | 現行版の基準確立 | テストログ、基準データ | 現行版の結果を保存した |
| Step 3 | 不具合の再現 | 最小再現テスト | 修正前の問題が再現できた |
| Step 4 | 修正・実装 | コード差分 | 変更理由を説明できる |
| Step 5 | 三言語比較 | Fortran/Python/Julia比較表 | 前提と許容誤差を揃えた |
| Step 6 | CIによる確認 | GitHub Actionsログ | 実行済みのテストが成功した |
| Step 7 | 人によるレビュー | レビュー記録、PR | 重要な計算条件を確認した |
数値解析では、「CIがPASSした」と「計算が妥当である」は同じではありません。 既知の解、検証データ、保存則、実測値との比較を別に設けます。
5.1 FortranとJuliaの比較結果をどう残すか
たとえば計算終了時の各断面水位を比較する場合、次のような指標を記録します。
- 最大絶対誤差
max(abs(h_fortran - h_julia)) - 平均絶対誤差
mean(abs(h_fortran - h_julia)) - RMSE
sqrt(mean((h_fortran - h_julia)^2)) - 総流入量・流出量・貯留量の整合性
- 実行時間（ウォームアップを含むかを区別）
JuliaのJITコンパイル時間を含む初回実行と、コンパイル後の定常実行は分けて測定します。Fortran側も最適化オプションを記録し、できるだけ同じマシン・同じ入力で比較します。
また、FortranのREAL*4とJuliaのFloat64では、精度条件が一致しません。厳密な比較が必要な場合は、Fortran側の宣言とコンパイラー設定を確認したうえでJuliaのFloat32等に揃え、丸め差の扱いも決めます。
6. dotへの最初の指示例
初回に与える指示は、やってほしいことだけでなく、どこまで自律的に変更してよいかも明確にすると扱いやすくなります。
初期設定用プロンプトを開く
あなたには、私の数値シミュレーション開発を継続的に支援してほしいです。
【対象】
- Ubuntu 24.04 LTSをPCへ直接インストールしたネイティブ環境
- Ubuntu上のDocker Engine / Docker Compose（Docker Desktopは使用しません）
- Ubuntu DesktopはChatGPT Linuxアプリのプレビュー版を利用可能
- Ubuntu Serverの場合はGitHub/Codexクラウド/CIを中心に連携
- Fortran 2018（gfortran / fpm）
- Python（FastAPI / pytest / ruff / mypy）
- Julia（数値解析・Fortranとの比較）
- GitHub / GitHub Actions
【優先順位】
1. 現状のファイル構成、環境、既存テストを調査する
2. 調査結果から、確認済みの事実と推測を分ける
3. 不具合は最小ケースで再現する
4. 作業ブランチで修正し、テストする
5. Fortran・Python・Juliaの数値的整合性を確認する
6. 差分、実行コマンド、ログ、残課題を報告する
【絶対に守ってほしいルール】
- 計算条件・境界条件を憶測で決めない
- 実行していないテストをPASSと報告しない
- 未確認のコードを「動作確認済み」と呼ばない
- mainへのマージや本番環境への反映は私の承認を必要とする
- 秘密情報、未公開データ、顧客データを外部送信しない
- ファイル削除、依存パッケージの導入、大量の計算資源を使う処理は事前確認する
- ソースには日本語の詳細コメントとdocstringを付ける
- 報告は自然な日本語の「です・ます調」にする
まずは接続状態と確認可能な範囲を教えてください。
アクセスできないリポジトリや環境については、アクセスできるようなふりをしないでください。
この指示は作業方針を示すためのものです。実際のアクセス制限は、dotの設定、接続アプリの権限、組み込みの安全機構で管理してください。文章で「禁止」と書くだけではOSやGitHubの権限設定の代わりになりません。
7. 定期的な仕事との相性
dotには、定期タスクの実行や、許可された情報源を使った先回りの情報確認の仕組みがあります。
開発向けには、たとえば「毎朝、許可済みGitHubリポジトリのCI失敗状況を要約する」「依存ライブラリの変更情報を調べ、更新候補をまとめる」といった作業が考えられます。
ただし、先回りリサーチは、接続アプリから情報を読み取る段階ではメッセージ送信、プラグインによるデータ変更、ブラウザーやコンピューターの操作を直接行わない仕組みです。調査結果を受けてコードを修正するような操作には、通常のタスク実行や承認の枠組みが適用されます。
定期的な作業についても、アカウントの利用枠、接続先の権限、ローカルPCの稼働状況などによって実行可能な範囲が変わります。
8. 安全性・機密データの扱い
ローカルPCや業務リポジトリに接続する前に、以下の点を確認しておきます。
- 最初は読み取り専用または検証用リポジトリから始めます。
- GitHubの接続権限は必要最小限に限定します。
- SSH秘密鍵、APIキー、個人情報、顧客の非公開データを会話やソースに直接貼り付けません。
- 本番デプロイ、データ削除、機密情報の外部共有、依存ツールの導入には承認を求める運用にします。
- 重要な数値計算の結果は、開発者自身が元データと計算条件を確認します。
- ChatGPTのモデル改善設定と、接続アプリからdotが取得した情報の扱いを確認します。
OpenAIの説明では、dotはChatGPTのメモリや最近の会話情報を受け取る場合があります。また、接続したアプリから得た情報を自身の文脈として保持することがあります。アプリを切断しても、過去に取得した文脈が自動削除されるわけではありません。 dot自体をリセットした場合も、別の保存先に作られたファイルやCodexスレッド等は個別に扱われます。
機密性の高いソルバーや顧客データの場合は、利用規約だけでなく、データの持ち出し範囲や社内規定も確認する必要があります。
9. 利用条件・導入方法
2026年10月14日時点の公式ヘルプでは、対象地域のProおよびBusiness Premiumに順次提供されています。Enterprise（Edu、Healthcareを含む）では、管理者が有効化することでベータ版を利用できます。18歳未満は対象外です。地域による制限や段階的な提供もあります。
最初のdotは対象のProまたはBusiness Premiumプランに含まれますが、高度な作業には利用枠があります。CodexやWorkに委任するタスクについては、それぞれの利用条件・使用量が適用されます。今後の追加dotや利用枠の提供方法は変わり得ます。
導入は、利用可能なアカウントでChatGPT dotsを開き、案内に従って作成します。デスクトップのWebブラウザーやChatGPTデスクトップアプリから操作できます。公式ヘルプには新しいモバイルアプリからの設定についても案内がありますが、画面や利用できる機能は段階的に変わる場合があります。
ローカルPCを使う場合は、ChatGPTデスクトップアプリでdotのプロフィールを開き、Computers → Your computer → Allow accessのような許可操作を行います。実際の画面表記はアプリの版によって異なる可能性があります。終了時はアクセスの取り消し（Revoke access）を確認します。
10. dotを使うなら、まず何から始めるか
Fortran・Python・Juliaを含む開発では、次の順序が取り組みやすいと思います。
最初の試験： GitHubにある小さな検証用リポジトリを対象に、dotとCodexでREADMEの修正や単体テストの追加を依頼します。利用権限、変更履歴、差分のレビュー方法を確認します。
次の試験： Pythonのテスト環境を整え、実際にpytestを実行したログを取得します。実行したコマンドと失敗理由が正しく報告されることを確かめます。
その次： Fortran 2018とJuliaの同一数値問題を用意し、両者の出力比較を行います。誤差指標と比較条件を固定し、CIで回帰テストできるようにします。
最後に： Ubuntu 24.04ネイティブ環境のDockerを使ったテストを段階的に検証します。まず開発者自身が手動で実行し、必要であればGitHub ActionsのSelf-hosted Runnerから同じ手順を実行します。Ubuntu Desktop上のChatGPTアプリを使う場合は、ローカル連携の可否・権限を別途確認してから対象を広げます。
おわりに
dotの面白いところは、ひとつの質問を解決するだけでなく、継続する開発の経緯、作業方針、次に調べることを管理できる点にあります。
Fortranで数値計算を行い、Pythonで周辺システムを作り、Juliaで計算手法を検証する構成であれば、言語ごとに分散した確認作業を整理できる可能性があります。その一方で、計算の妥当性を判断する役割や重要な変更を承認する役割は、引き続き開発者が担います。
Ubuntu 24.04を直接利用する構成なら、Fortran・Python・Juliaの実行環境をLinuxに統一しやすくなります。最初からすべてを自動化しようとせず、小さなテスト → 実行結果の確認 → 許可範囲の拡大という順序で進めるのが現実的です。
参考資料
- OpenAI（2026年9月29日）「dots のご紹介」
- OpenAI Help Center「dot スタートガイド」
- OpenAI Help Center「Getting started with your dot（英語原文）」
- OpenAI Help Center「Dots privacy, security, and safety FAQs」
- OpenAI Help Center「ChatGPT Work and Codex」
- OpenAI Help Center「Manage dots in ChatGPT workspaces」
- OpenAI「ChatGPT desktop app for Linux（Ubuntu 24.04 LTS対応）」