AIの並列実行はマルチタスクではない

最近、AIを使って開発や調査を進めていると、「AIを並列で動かせるなら、人間もマルチタスクできるようになる」と捉えられることがあります。ただ、個人的にはこれは少し違うと思っています。AIを複数並列で動かせることと、人間が複数のタスクを同時に処理することは別物です。

そもそもマルチタスクとは何か

ここでいうマルチタスクは、「複数の作業が同時に存在している状態」のことではありません。実務では、複数のタスクを同じ日に扱うこと自体は普通にあります。

たとえば、エンジニアの1日には次のようなことが並びます。

新機能の設計
既存コードの調査
Pull Requestのレビュー
不具合調査
お問い合わせ対応
チームメンバーとの仕様確認
リリース前の確認
ドキュメントやブログの作成

これらが同じ日に存在しているだけなら、それは単に「複数のタスクを持っている状態」です。

自分が避けたいと思っているマルチタスクは、もっと細かい時間単位で、複数の思考コンテキストを頻繁に切り替える状態です。

たとえば、次のような状態です。

新機能の設計を考えていたのに、途中で不具合調査に切り替える
不具合の原因を追っていたのに、途中で問い合わせ対応に切り替える
問い合わせ対応で仕様を確認していたのに、途中でPull Requestレビューに切り替える
レビュー中に別の設計相談が入り、また元のレビューに戻る
ブログを書いていたのに、途中で実装方針の調査に切り替える

このような切り替えが短い間隔で何度も起きると、かなり疲れます。

なぜなら、それぞれのタスクには別々の前提があるからです。

新機能の設計では、ユーザー体験、既存仕様、データ構造、API設計、リリース順序などを考えます。
不具合調査では、再現条件、ログ、影響範囲、過去の変更履歴、修正方針を追います。
お問い合わせ対応では、ユーザーが何に困っているのか、仕様として正しい挙動なのか、返答に必要な情報は何かを整理します。
Pull Requestレビューでは、変更意図、設計の妥当性、テスト観点、既存コードとの整合性を見ます。

これらはすべて、頭の中で持つべきコンテキストが違います。つまり、マルチタスクの負荷は「作業数が多いこと」そのものではなく、短時間で何度もコンテキストを切り替えることにあります。

この感覚は、心理学でいうタスクスイッチングの話に近いです。

American Psychological Associationの記事でも、マルチタスクは「同時に複数のことをする」だけではなく、タスクからタスクへ切り替えたり、短時間に複数のタスクを連続して処理したりすることとして説明されています。そして、複雑なタスクほど切り替えのコストが効率や正確性に影響しやすいとされています。

自分の中では、人間のメインスレッドは基本的に1つです。深く考える必要があるタスクを同時に複数持つのではなく、今集中する対象は1つに絞る。その前提に立つと、AIの並列実行は人間のマルチタスクとはまったく別物として捉えられます。

むしろ、AIをうまく使うほど、人間側は「いかにマルチタスクしないか」が重要になります。

AIの並列実行は、人間のマルチタスクではない

AIを使うと、複数のタスクを同時に進めることができます。

たとえば、メインでは新機能の設計を考えながら、裏側ではAIに次のようなことを任せられます。

既存コードベースの調査
バグ修正の影響範囲の確認
テストケースの洗い出し
セキュリティ対応の調査
お問い合わせ内容に関する仕様確認
ブログを書くための関連情報調査
実装方針の比較案作成

これは一見するとマルチタスクに見えます。

ただ、実際に人間がやっていることは、複数のタスクを同時に考えることではありません。

人間はあくまで、メインのタスクに集中しています。その裏側で、AIが調査や整理を進めてくれているだけです。

構造としては、人間のメインスレッドでは重い判断、設計、実装、コミュニケーションに集中します。

一方で、AIのサブスレッドでは、調査、整理、影響範囲確認、テスト観点出しなどを並列で進めます。

重要なのは、人間の集中先を増やすことではありません。

人間が集中する対象は1つに絞ったまま、周辺の調査や準備をAIに任せることです。

30〜40分単位で区切ると扱いやすい

自分の感覚では、AIの並列実行は30〜40分くらいのタイムボックスと相性が良いです。

たとえば、最初の数分でタスクをざっと見ます。その中から、今いちばん人間が集中すべきメインタスクを1つ選びます。それ以外のタスクについては、AIに調査や整理を依頼します。

最初の2〜5分では、タスクをざっと見て、人間がメインで取り組むタスクを1つ決めます。残りのタスクから、AIに任せられる調査や整理を切り出して依頼します。
次の30〜40分は、人間はメインタスクに集中します。AIは裏側で調査、整理、検証を進めます。
区切りのタイミングで、AIの結果を見て、状況を再評価します。そのうえで、次に人間が取り組むタスクと、AIに渡すタスクを決めます。

この流れにすると、人間はマルチタスクせずに済みます。一方で、AIは裏側で複数の調査や設計補助を進めてくれます。結果として、待ち時間や調査時間をかなり圧縮できます。これは、ポモドーロテクニックやタイムボックスの考え方にも近いです。

ポモドーロテクニックは、25分程度の集中時間と短い休憩を組み合わせる時間管理手法として知られています。ここで大事なのは、25分という数字そのものではなく、一定時間は対象を絞って集中し、区切りで見直すことです。

また、スクラムなどで使われるタイムボックスは、活動に使う最大時間をあらかじめ決める考え方です。AIの並列実行でも、同じように「この時間で何を進めるか」「区切りで何を見直すか」を決めておくと扱いやすくなります。

自分の場合、25分だとAIの調査が少し浅く終わることがあります。一方で、1時間を超えると人間側の集中が切れたり、AIの結果を確認するタイミングが遅れたりします。その中間として、30〜40分くらいがちょうどよい感覚です。

調査が大きな割合を占めるタスクは多い

開発タスクは、実装だけで完結することはあまりありません。

新機能開発であっても、まず既存コードを調べます。
お問い合わせ対応でも、仕様やログや過去の経緯を確認します。
バグ修正でも、影響範囲や再現条件を調べます。
ブログを書く場合でも、関連する情報や事例を調べます。

つまり、多くのタスクには調査フェーズがあります。そして、この調査フェーズはAIと相性が良いです。

もちろん、最終的な判断は人間が行う必要があります。AIの出力をそのまま信じるべきではありません。ただ、最初のたたき台を作る、観点を洗い出す、関連箇所を探す、比較材料を出す、といった作業はAIに任せやすいです。

実際、1つのタスクのうち半分くらいは、AIが調査・整理・設計補助として先に進められることもあると思っています。

メインに置くべきなのは、人間が考える必要があるタスク

AIを並列で動かすときに重要なのは、「何をメインに置くか」です。メインに置くべきなのは、重い判断が必要なタスクです。

たとえば、次のようなものです。

プロダクトとして何を優先するか
仕様をどう切るか
設計としてどの方針を採用するか
チームメンバーや関係者とどう合意を取るか
実装上のトレードオフをどう判断するか

こういったタスクは、人間がしっかり考える必要があります。

一方で、その周辺にある調査や整理はAIに任せやすいです。

たとえば、メインでは設計を考えながら、裏側ではAIに既存実装の調査をさせる。メインではチームメンバーと仕様を詰めながら、裏側ではAIにテスト観点を洗い出させる。メインではブログの構成を考えながら、裏側ではAIに関連する論点を調べさせる。

このように、人間が考えるべき中心を1つに絞り、その周辺をAIで並列化するのが良いと思っています。

AIに任せるタスクは、複雑な仕組みで管理しなくてもよい

AIの並列実行というと、専用のタスクキューや複雑な管理ツールが必要に見えるかもしれません。ただ、自分の感覚では、最初からそこまで複雑にしなくても十分です。特別なプラグインやスキルを使わなくても、かなりの量を並列で進められます。今のAIは、ある程度の粒度でタスクを渡せば、かなり自律的に進めてくれます。

大事なのは、ツールを増やすことではありません。大事なことは、AIに渡すタスクをシンプルにすることです。

たとえば、

「この機能の既存実装を調べて、関連するファイルと処理の流れを整理してください」と依頼します。
バグ修正であれば、「この修正の影響範囲を調べて、注意すべきテスト観点を出してください」と頼みます。
問い合わせ対応であれば、「この問い合わせ内容について、仕様上確認すべきポイントを洗い出してください」と依頼します。
ブログであれば、「この論点に関連しそうな観点を整理してください」と頼みます。

このくらいの粒度であれば、十分にAIへ任せられます。タスク管理を高度化する前に、まずは「AIに渡しやすい粒度に分ける」ことの方が重要だと思います。

おまけ

普段はClaudeを使用していますが、何度も許可を出すのが面倒なときは、許可モードを調整できます。

Claude Codeの公式ドキュメントでは、Shift+TabでAuto-Accept Mode、Plan Mode、通常モードを切り替えられると説明されています。また、手元のclaude --helpでは、起動時に--permission-modeでacceptEditsやbypassPermissionsなどを指定できることを確認できました。

編集だけをある程度任せたいなら、acceptEditsを使う選択肢があります。

claude --permission-mode acceptEdits

ただし、ツール実行まで広く自動承認するモードは、対象ディレクトリ、ネットワーク、秘密情報、実行されるコマンドの権限を確認したうえで使った方がよいです。codexでは、手元のcodex --helpで--full-autoが「低摩擦なサンドボックス内の自動実行」として用意されていることを確認できました。

https://developers.openai.com/codex/cli/reference

codex --full-auto

geminiでは、手元のgemini --helpで--yoloオプションと--approval-mode yoloが用意されていることを確認できました。

https://geminicli.com/docs/reference/configuration/

gemini --yolo

コンフリクトするタスクは同時に走らせない

AIを並列で動かすと、当然リスクもあります。特に開発では、複数のAIに同じファイルや近い領域を触らせると、コンフリクトが起きやすくなります。ただ、これはAI特有の問題というより、タスク分割の問題です。同じファイルをAタスクとBタスクで同時に変更すれば、人間同士でもコンフリクトします。なので、基本的には同じ領域を同時に大きく触らせない方が良いです。

たとえば、次のように分けると扱いやすいです。

実装タスクは人間がメインで進める
AIには周辺調査をさせる
AIにはテスト観点を出させる
AIには影響範囲を確認させる
AIには別領域の小さな修正案を出させる

もちろん、コンフリクトが起きることもあります。ただ、同じ人間が全体のコンテキストを持っていれば、その情報を使って後続タスクで解消することもできます。重要なのは、AIを無秩序に走らせることではありません。

同時に走らせても問題が起きにくいタスクを選ぶことです。

AIが空いているから何かをやる、は危ない

AIを並列で使えるようになると、「AIが空いているから何かやらせよう」と考えたくなります。

ただ、これは少し危ないです。

たとえば、次のような動きです。

AIが空いているからテストを増やす
AIが空いているからリファクタリングする
AIが空いているから細かい改善を探す
AIが空いているから何か調べさせる

これらが完全に不要というわけではありません。ただ、本当に今やるべきかは別です。 AIがあるからといって、優先順位の低いタスクを大量にこなしても、プロダクトは前に進みません。 AIの並列実行は、ロードマップやチームの優先順位に沿ったタスクを速く進めるために使うべきです。

「AIが空いているから何かをする」 のではなく、「やるべきタスクの中から、AIに任せられる部分を先に進める」 という考え方の方が健全だと思っています。

ブログを書くときにも同じ構造になる

これは開発だけの話ではありません。ブログを書くときにも、同じような構造になります。自分の場合、ブログの本文を最初から全部AIに書かせるというより、自分で話したいことや構成を考えます。そのうえで、途中途中に「くさび」を打つような感覚で、AIに調査や整理を依頼します。

たとえば、次のような使い方です。

この論点に関連する観点を出してもらう
似たようなテーマがないか調べてもらう
自分の主張に抜け漏れがないか確認してもらう
読者に伝わりにくそうな部分を指摘してもらう
反論されそうなポイントを整理してもらう

この場合も、人間のメインスレッドは「何を言いたいか」を考えることです。 AIは、その周辺で調査や整理を手伝ってくれる存在です。ブログを書くこと自体も、完全にAIに任せるというより、人間の思考を中心に置きながら、周辺作業をAIで並列化する方がしっくりきます。

AI時代に大事なのは、集中する対象を間違えないこと

AIを使うと、確かに多くのことを同時に進められます。ただ、それは人間がマルチタスクをすべきという意味ではありません。

むしろ逆 です。

AIが裏側で複数のタスクを進めてくれるからこそ、人間はメインのタスクに集中しやすくなります。上記でも例として出しましたが、自分の中では、AI活用の基本形はこうです。

最初の5分で、タスクをざっと見て、メインで取り組むタスクを1つ決めます。残りのタスクから、AIに任せられる調査や整理を切り出します。
次の30〜40分は、人間が1つの重いタスクに集中します。ペアプロや設計相談など、人間同士の濃いコミュニケーションもこの時間に置きます。AIには、周辺の調査、整理、検証、設計補助を並列で進めてもらいます。
次の5分で、AIの結果を見て、状況を再評価します。次に人間が取り組むタスクを決め、AIに次のタスクを渡します。

この流れを繰り返すことで、AIの並列実行の恩恵を受けながら、人間はマルチタスクに振り回されずに済みます。 AIを並列で動かすことは、人間が複数のことを同時に考えることではありません。

人間の集中は1つに保つ。その裏側で、AIに複数の準備を進めてもらう。

これが、今の自分にとって一番しっくりくるAIの使い方です。

まとめ

AIの並列実行と、人間のマルチタスクは別物です。 AIを複数動かせるからといって、人間が複数のタスクを同時に考える必要はありません。むしろ、人間のメインスレッドは1つに絞るべきです。そうすると、人間は集中を保ったまま、タスク全体の進みを速くできます。 AIによって重要になるのは、何でも同時にやることではありません。

何に集中するか、何をAIに任せるかを切り分けることが重要です。