AIは並列に動けるのに、なぜ僕は直列でしか考えられないのか

この記事は、Unipos Advent Calendar 2025の2日目の記事です。

背景

AIエージェントを日常的に使っているのに、複数タスクを同時に任せるのがどうも苦手だ。ミーティング中に裏で実装を進めてもらったり、作業中に過去ログ分析を走らせたり、便利なのは理解してるのに、どこかザワザワする。「これ、普通に任せればいいんだよな……？」と思いながら、身体が追いつかないあの感じ。

この違和感を説明するうえで、自分の中にしっくりきた比喩がある。それが「人間は太古のOSの上で動いている」という考え方だ。僕らの脳は“直列処理が正義だった原始時代”からの設計思想がまだ残っている。だからAIの非同期・並列処理と噛み合わない。

人間の脳はそもそも「直列」前提でできている

原始時代、命を守るために必要だったのは“一点集中”だ。「背後で音がした。獣か？」という場面で別のことを考えていたら即アウト。だから脳は「危険に対して全リソースを割く」方向に進化した。

無意識は視覚・聴覚・姿勢制御などを完全に並列で処理している一方、意識は常に直列。複数の判断が同時に走ると競合が起きて、行動が乱れる。結果、脳は「意識で扱うのは一度に一つ」が最適解になった。

さらに僕らは物事を“物語”として理解したがる。Aが起きてBが起きた、という因果の流れがあると安心する。逆に非同期で複数の物事が同時進行すると“ストーリーが見えない”ので無意識に不安を感じる。

そして“自分で制御できている状態”に快楽を感じるのも原始時代の名残だ。予測できない変化＝危険、という環境だったため、外で勝手に処理が動いている状況は本能的にストレスになる。AIに裏で作業を任せていると妙にソワつくのは、まさにこの古いOSの仕様だ。

Claude Codeで“自分の並列耐性”を可視化してみた

構造は理解できたものの、実際にどれくらいAIを並列で使えているのかは体感だと曖昧。そこでClaude Codeのhooks機能を使い、タスク依頼のイベントログを記録して並列度を可視化することにした。どのタイミングでどんな処理を依頼し、どれくらい同時に走っているのかを捉える狙いだ。

Claude Codeのフックリファレンス

設計

仕組みは、hooksで得たJSONLをGoのCLIで扱いやすいCSVに変換し、簡単なバックエンド・フロントエンドで可視化するだけ。実装はVibe Coding経由でAIにほぼ任せ、必要な部分だけ自分で補った。

アーキテクチャ

層	役割	主要コンポーネント
層1	インフラ層	Claude Hooks → JSONL
層2	メトリクス生成層	JSONL(Go CLI) → CSV
層3	可視化層	Backend → Frontend

実際の画面

1画面目	2画面目

実装してみての所感

結果はかなり分かりやすかった。「自分はほぼ直列でしかAIに依頼していない」感覚としての“並列が苦手”がそのままデータに現れた。だいたい1つずつやっている。多くて、今やっているタスクを依頼。次いで、次のタスクの調査、同僚からのレビュー。の多くて3並列ぐらい。

Vive Codingだったので他にも色々機能をおまけでClaude Codeが作ってくれた中での気付きとして、Claude Code自体を並列で扱うという点以外に、Claude Code内の1セッション内で、どのぐらい並列でタスクを進めてもらえるかという視点もあることに気づいた。

AI時代を生きる「直列OSとしての人間」

AIは非同期・並列が当たり前で、タスクを同時に投げればどんどん処理してくれる。しかし僕らの脳は依然として直列OSのままだ。このギャップをどう扱うかが、これからのAI活用における大きなテーマになる。

今回の可視化は、まず自分の“OSの癖”を理解するための小さな実験だった。無理に並列人間になる必要はないけど、自分の処理構造を把握しておくと、AIへのタスクの投げ方や設計が変わる。
今後は、どこをAIに任せ、どこを人間側の直列処理に残すのか。両者の境界をうまく設計する働き方を探っていきたい。