私のAI環境の見取り図 — ひとりの技術者がAIに何を任せているか

ここ一年で、私の仕事の進め方は大きく変わった。以前は、調べ物も、サーバーの操作も、原稿の下書きも、すべて自分の手でやっていた。今はその多くをAIに任せている。しかも、ただ質問して答えをもらうだけではない。AIが実際にサーバーへ入って設定を直し、チケットを起票し、ブログに記事を投稿し、ときには自分自身のプログラムまで書き換えている。

あれこれと手を広げすぎて、自分でも全体像を説明するのが難しくなってきた。個別の話を一つずつ取り出すと、木を見て森を見ない話になる。だから一度、森のほうを描いておこうと思う。この記事は、私のAI環境の「見取り図」だ。細かい作り込みは追わず、どの層に何があって、どこで人が関わっているかだけを示す。各論は、この図から枝分かれする形で別の記事に書いていく。

全体像：4つの層

私の環境は、大きく4つの層でできている。上から順に、私が触る場所、私が作った場所、AIが働く場所、そしてAIが実際に手を動かす先だ。

この4層を、上から順に見ていく。

① 対話層 — 私が話す窓口

入口はチャット画面だ。私はここでAIと会話しながら作業を進める。思いつきをその場で投げ、返ってきた答えを見ながら次の手を決める。調べ物も、サーバーの操作も、原稿の下書きも、原則はこの会話の中で完結する。

この画面には定期実行の機能がある。毎朝決まった時刻に、会話を自動で立ち上げて処理を走らせている。私が手で起動するのではなく、決まった時刻に無人で動く仕事がいくつかある。朝、画面を開くと、夜のあいだに走った処理の結果が並んでいる。この「私が起動しなくても動く」という性質が、後の層の話につながっていく。

② 基盤層 — 私が作った中核

対話層の下で実際に会話を組み立てているのが、私が自分で書いた中核サーバだ。既製品を使わず自作したのには理由がある。道具の選ばせ方とプロンプトの組み立てを、自分の判断で細かく制御したかったからだ。

このサーバは同じマシンの上に、本番用と開発用の2系統を並べて動かしている。新しい機能はまず開発用に入れて確かめ、問題がなければ本番用へ回す。順番は必ず「開発 → 本番」で固定した。勢いでいきなり本番を触ると、自分が使っている環境ごと壊しかねない。

この層の中心にあるのが「道具箱（ツールボックス）」という考え方だ。AIに最初からすべての道具を見せるのではなく、いま必要な分野の道具だけを束にして渡す。ファイル操作ならファイル操作、会計なら会計、というように、会話の目的に応じて道具の束を丸ごと差し替える。

これは地味だが効く。道具を全部並べておくと、AIは使わない道具まで視野に入れて迷い、的外れな操作をしかねない。選択肢は、多いほどよいとは限らない。そのときの仕事に必要な道具だけを渡し、終わったら仕舞う。人間が作業台の上を整理するのと同じことを、機械の側でもやっている。

もう一つ、この層には「止めずに直す」仕掛けを入れてある。プログラムのファイルを書き換えると、次の処理から新しい内容が読み込まれる。実行中の会話を切らずに、動かしながら中身を差し替えられる。これがあるおかげで、AIが自分で自分の環境を直しても、その場で会話が途切れない。

③ 実行層 — 役割ごとの担当者

その上で働くのが、役割ごとに分かれたAIの担当者たちだ。今のところ12種いる。それぞれが自分の道具箱を持っていて、自分の専門の外へは出ない。

• タスク管理を担う担当者（チケットの起票・調査・更新）
• インフラ構築を担う担当者（サーバ構築・設定の自動化）
• ブラウザ操作を担う担当者（管理画面の操作・画面確認）
• 記事化を担う担当者（下書きの生成・素材収集・通知）
• 画像生成を担う担当者
• 会計を担う担当者
• 物理サーバの電源操作を担う担当者
• 動画の要約を担う担当者
• 障害アラートの一次調査を担う担当者
• 自分の本体プログラムを差し替える担当者
• 再起動を安全な瞬間まで繰り延べる担当者

ここで狙っているのは、汎用の何でも屋を一つ置くのではなく、専門を分けて足し算することだ。何でも屋は、何にでも手が届く代わりに、どの分野でも半端になりやすい。担当を分けておけば、ある分野の手順を磨き込めるし、その分野だけを差し替えるのも簡単になる。

④ 連携先層 — AIが実際に手を動かす先

いちばん下の層が、AIが実際に触る相手だ。ここが、この環境の性格をいちばんよく表している。

• タスク管理の基盤（チケットの起票から完了まで）
• ブログ（記事の投稿・画像の設定）
• アクセス解析と検索の分析（数値の取得と解釈）
• 表計算と、その上で動く自動化スクリプト
• 会計（仕訳・試算表）
• 通知（日々の連絡を受け取る場所）
• 動画（要約の材料）
• 手元のサーバ群とサーバ基盤（構築・監視・復旧）

私が使っている道具は、いわゆる「ひとつのサービスに全部入り」ではない。性質の違う道具が並んでいて、その一つひとつにAIが手を伸ばしている。この「複数の道具をまたいで動く」ところが、普通のAI利用とのいちばん大きな違いだと思っている。

何が普通と違うのか

全体像を描いたところで、私自身が「これは普通とは違うな」と感じている点を4つ挙げておく。

1. AIがAI環境そのものを改修する

ふつう、AIは既製品のサービスを使う側にある。私の場合は違う。AIを載せている土台そのものを、AIが毎日のように書き換えている。変更は一日で100件を超えることも珍しくない。しかも、その書き換えのほとんどは、私がパソコンの前にいなくても進む。

止めずに直す仕掛け（ホットリロード）と、再起動を安全な瞬間まで繰り延べる仕掛けの両方を入れてあるので、更新のたびに環境が止まることはない。使っている最中に裏で中身が入れ替わっている、という状態が常態になっている。

2. 道具を必要なときだけ注入する

前述の道具箱の話だ。AIに渡す道具を、その都度の目的に合わせて絞る。渡しっぱなしにしない。これは機能の話であると同時に、失敗を減らすための設計でもある。手元にないものは選べない。逆に言えば、関係ない道具を最初から見せないだけで、余計な寄り道がぐっと減る。

3. ブログはAPIで、自動化スクリプトはブラウザで

相手ごとに、触り方を変えている。ブログは正式なAPIがあるので、そこから投稿する。一方、ブラウザ上でしか編集できない自動化スクリプトのようなものは、ブラウザを人間の代わりに操作して更新する。

これは「楽なほうを選ぶ」という話ではない。公式の入口があるならそこを使い、無いなら人間と同じ手順を機械に再現する。入口の有無を見極めてから手段を決める、という順番を守っている。相手をよく見ずに、いつも同じやり方で押し通すのがいちばん危ない。

4. 半自動の作法 — 人間の確認を必ず挟む

自動化を進めるほど、どこで人が止めるかを決めておかないと危うくなる。私の環境では、タスクの起票の前と、完了の直前の二か所に、必ず人間の確認を挟んでいる。

起票前には「この内容で登録していいか」を確認する。完了時には「この結果で検収OKか」を確認する。AIに任せる範囲を広げつつも、節目だけは自分で押さえる。この二つの関所を設けてから、任せる量を増やしても不安がなくなった。

記憶を一枚の地図にする — 統合検索とグラフビュー

私の環境には、会話の窓口であると同時に、自分が過去に何を見て、何を話したかを眺め直すための画面がある。「AIダッシュボード」と呼んでいる自作のツールで、これも①の対話層に同居している。

中心にあるのは、統合検索だ。私の環境では、AIとのチャット履歴だけでなく、スマホで見たサイトの閲覧履歴（主にニュースサイト）も、本文ごと取り込んで意味を表すベクトルに変換してある。だから「あのとき読んだ、あの話題」を、言葉の一致ではなく意味の近さで引くことができる。会話履歴と閲覧履歴という、本来は別々の場所に散らばっている記録を、同じ一つの検索窓から横断して引ける。検索語は自然言語でよい。意味で引くか、言葉で引くか、両方を混ぜるかを選べるようにしてあり、日付の古さをどれだけ割り引くかも自分で調整できる。

もう一つが、グラフビューだ。検索が「近いものを上から順に並べる」のだとすれば、グラフビューは「近いものを、近くに置く」。取り込んだ記録のすべてを意味の座標に置き直し、似ているもの同士を引き寄せて、一枚の2次元の地図に配置する。出来上がるのは、話題ごとの「島」が浮かぶ海図だ。モータースポーツの話は一帯に固まり、天気の話は別の方角に離れる。島の名前は、そこに集まった記録の見出しから自動で付く。

この地図は、色の塗り方を三通りに切り替えられる。記録の新しさで塗れば、最近よく触れている話題が浮かび上がる。話題の島で塗れば、自分の関心がどんな塊になっているかが見える。記録の出どころで塗れば、チャットで話したこととスマホで読んだことが、それぞれどこに沈んでいるかが分かる。地図の上で一点を選ぶと、その点を中心に類似度を計算し直し、つながりの強い相手を金色の線で浮かび上がらせる。検索語を打てば、地図の上に★が立ち、そこから意味の近い記録が扇のように広がる。

面白いのは、この地図の上では、AIとのチャット履歴と、スマホで見たニュースの閲覧記録が、同じ平面に並んでいることだ。話したことと読んだことが、話題の近さだけで隣り合う。自分でも意識していなかった結び付きが、距離として目に見える。記録を検索して取り出すのではなく、記録のほうを一枚の地形として眺められるようにした、というのがこの画面の狙いだ。

なぜこの形になったのか

振り返ると、この環境は計画的に設計したというより、必要に迫られて少しずつ育ってきた。最初は普通に質問するだけだった。次に、繰り返しの作業を任せるようになり、やがてサーバーを触らせ、最後には環境そのものを直させるようになった。任せる範囲が広がるたびに、事故らないための柵を一本ずつ足してきた。それが今の4層の形になっている。

一貫してきた方針は、次の三つだ。

• 再現したいものだけを、手順として残す。使い捨ての作業は、その場でさっと終わらせる
• 変更は必ず記録に残す。あとから戻せるようにしておく
• 人の確認が要る場所と、要らない場所をはっきり分ける

派手な機能は一つもない。あるのは、地味な安全策の積み重ねだ。だが、この積み重ねがあるからこそ、任せる量を思い切って増やせる。

この先の記事について

この見取り図から、各論を枝分かれさせて書いていく予定だ。予定しているのは、次のようなものだ。

• 土台の仕組み（会話の組み立てと道具箱）
• タスク管理をAIに任せる
• インフラ構築をAIに任せる
• ブログ投稿をAIに任せる
• 表計算と自動化スクリプトをAIに更新させる
• 障害アラートの一次調査をAIに任せる

いずれも、この一枚の図のどこかに位置づく話だ。逆に言えば、先にこの見取り図を置いておけば、個別の話がどこに収まるのかが読んでいて分かるはずだ。すでに一本、自動でチケットを起こす仕組みについて書いた。その話も、この図のタスク管理の枝に連なる。

まとめ

私のAI環境は、対話・基盤・実行・連携の4層でできている。入口は私が話すチャット画面で、その下に自作の中核があり、その下で役割ごとのAIが働き、いちばん下で複数の実際の道具に手を伸ばしている。

普通のAI利用との違いは、AIが環境そのものを改修していること、道具を必要なときだけ渡していること、相手に応じて触り方を変えていること、そして要所に人間の確認を残していることだ。

AIに何を任せるかは、技術の話である以上に、任せ方の設計の話だと思う。何を任せ、どこで人に戻すか。その線引きを自分の手で決められることが、この環境を育ててきた原動力になっている。