AISI - AI で SI を変革する
はじめに
生成 AI を活用してうんぬんは SI にも当てはまるし、当てはめないといけない。SIer に限らず、少子高齢化による労働力の減少は無視できず、何もしなければ良くて縮小、悪くて破滅する。我々 SE の首も締まりかねないし、どうせ上は逃げ切れるだろうから本気じゃない。自分達で活路を開いていきたい。
また、AI が仕事を奪う的な話もよくあるが、生成 AI もまた効率化の道具にすぎない。ただし効率化の積み重ねが、魔法のような劇的な変化を生む。PC、スマホ、その他のテクノロジーと同様、使えない者は停滞・脱落するだけだ。そういう意味でも、生成 AI への取り組みは自己投資にもなる。
おそらく本記事の読者であれば、すでに生成 AI を使っているだろう。それでもいいが、方向性がわからないと先に進みづらいし、仕事にも繋げづらい。というわけで、AI x SI――その名も AISI（アイシー？）とでも名付けて、利活用の方向性を検討したい。
前提
まずは、本記事で取り上げる「SI」とは何かを定めておきたい。あらゆる SI を含むわけではない。
大体のニュアンス
上記記事で書いた SI や SIer を引き続き想定する。改めて書くと「中小よりも大手」「n次請けよりも元請け寄り」「アジャイルよりもウォーターフォール的な価値観」「アプリよりはインフラ寄り」という感じ。当てはまらない場合はご容赦ください。
加えて、もう二つほど定義したい。
強制約活動
造語だが、強制約活動 とは、管理的な制約に従うことを第一とした開発を指す。
予実管理がまさにそうだが、まず予定をつくって、そのとおりに行動して、本当に予定通りかをチェックして正すという営みだ。開発フローで言えば、まず要件や設計をつくってから、そのとおりに開発する。サイクル回して良いモンつくっていきましょうとか、つくったモンをリリースして反応見ましょうではなく、事前につくった（or つくられた）制約どおりに動くことが第一である。極論を言えば、開発した製品やサービスの品質や反応がイマイチでも、制約に従えているならそれでいい。
SI は強制約活動と言っていい。なぜそうなるかというと、SI の本質が保険屋だからである。システムという本質的に複雑なものの責任を負ってほしい――ここに需要があり、SIer が供給している。では責任を取るにはどうすればいいかというと、制約をつくって合意を取って、あとは制約を守りますとすればいいわけだ。無論、人間向けの制約とは自然言語であり、したがって SI ではドキュメントを先に（そしてたいていは大量に）つくることになる。
要は契約や約束であり、ビジネスでは至って普通だが、SI で扱うのは「本質的に複雑なシステム」だ。ルールや条項の比ではない。制約の量はアホみたいに多くなるし、うまく表現するための独自用語や定義も増えるし、そういった歴史的資産も継承されて使われ続ける。
また、こういった制約をかんたんに書く・描くのは難しいため、それなりに何でもできてよく知られたツールに頼ることになる――そう、Office だ。特に Excel は非常に便利なのである……。
DCPC
同様に造語だが、以下の略である。
- Document（ドキュメント、文書）
- Code（コード）
- Parameter（パラメーター、設計上の設定値）
- Configuration（コンフィグ、実機上の設定値）
対応としては、次のとおり。
- ドキュメントという制約から、コードをつくる（制約どおりに実装する）
- パラメーターという制約から、コンフィグをつくる（制約どおりに構築する）
つまり SI では、強制約活動を行うために、DCPC をつくる。
まとめ: AISI における前提
AISI で扱おうとする SI は強制約的であり、DCPC に従っている。
たとえば、以下のような事情がある:
- ドキュメントどおりにコードを、パラメーターどおりにコンフィグをつくらねばならない
- ドキュメントやパラメーターと、コードやコンフィグの整合を取らねばならない
- 強制約である以上、ドキュメントやパラメーターがマスターである
- しかし実際のシステムはコードとコンフィグである
- というわけで二重管理の宿命を背負わされている
- ドキュメントやパラメーターは人間が読むものであり、高級な表現が使われている（Excel など）
- コードやコンフィグのレビューも必要であり、もちろんちゃんとしたかを示すため証拠も残さねばならない（エビデンス）
- 何なら実装や構築時も「本当に制約のとおりにやったんだよな？」を示すために、エビデンスを残さなけれればならない（スクショ取りながら作業する等）
こういった営みを AI にやらせるか、AI で支援しなきゃいけない。
DX の思想で行くなら「そもそも SI の強制約的なスタイル自体を変えて、AI ベースのスタイルにした方がいいのでは」なのだが、SI は強制約活動である。ここでは考えない。強制約活動を AI でカバーしなきゃいけない のだ。
一行まとめ
AISI では「SI という強制約活動を AI でカバーするには？」に取り組みます。
※
以降では、
- 生成 AI ≒ LLM（大規模言語モデル）として話を進める
- ドキュメントと書いたり、文書と書いたりする。文書を使うことが多いが、同義だと思ってほしい。
==== AISIの全体像 ====
次に、前提を踏まえた前で、どうアプローチしていくかを見ていく。まずは全体像を眺める。
3点で
- 1: 情報を引き出す
- 人間から引き出す
- DCPC から引き出す
- 2: 情報を LLM に渡す
- 3: 情報を使って実装や構築を行う
3点 + 手法
- 1: 情報を引き出す
- 人間から引き出すための「チャット・ストーミング」
- DCPC から引き出すための「収集」
- 2: 情報を LLM に渡す
- Markdown 前提で立ち回る「Markize」
- 埋め込みベクトル化を継続的に行う「継続的エンベディング」
- 3: 情報を使って実装や構築を行う
- AI を用いた省力化や AI への委譲を行う「デリファメーション」
==== 各手法 ====
各手法・アプローチを詳しく見ていく。
チャット・ストーミング
問題解決のアプローチ
文章で説明しづらいので、まずは箇条書きで述べる。
背景:
- 情報は人間が持っている
- 情報は基本的に私たち人間が持っており、引き出さねばならない
- エンジニアリングも例外ではなく、チーム内で出し合うための組織づくり、組織論は山ほどあるし、顧客からうまく引き出すための原則もアジャイルやドメイン駆動設計など古くから抽出されてきた
- チームの時代やプロジェクト・エコノミーとはよく言ったものだ。いまや優秀でも嫌な奴は排除される（例: ブリリアントジャーク）し、何事もプロジェクトをつくる形で推進されていく
- テキスト + 非同期で十分でしょ → いいえ
- 個人的には、テキスト + 非同期で十分と考えていたし、そのためのやり方や考え方は過去 Remotism やタスク管理を噛み砕くで網羅してきたが、どうにも刺さらない
- 早い話、テキストコミュニケーションのリテラシーを万人に期待するのは無理ゲーのようだ。むしろ、従来どおり会話の営みをベースにして、いかに情報を引き出すには、を考えた方が良い
- 音声の時代？
- 生成 AI のおかげで音声認識、文字起こし、またその加工が現実的な精度とスピードで可能になった
- 例: AudioPen
問題
- 情報の出し合い方が甘い
- 原始的で人間的なやり方にとどまっている。優秀な人と「その組織に合う人」しか馴染めず、再現性がないか高コスト
- しかしテキスト + 非同期で割り切ることもできそうにない
解決策
- 原始的で人間的な「喋る」営みにて情報をたくさん出させて、それを、生成 AI を駆使して加工する
チャットストーミング
というわけで、チャット・ストーミング（Chat Storming を考える。
ブレストとして知られる「ブレインストーミング」からもじっており、チャット（おしゃべり）をしまくることで情報が出まくることを期待する。
最もわかりやすいのは会議の全録音、全文字起こし、それを LLM で要約することだが、この程度ならすでに実現できている。むしろ、この前提で、いかに会議データを貯めて、関連づけて、インサイトに導くかの戦いになっている。私が知っているのは tl;dv だが、類似製品は多数あるだろう。また個人用だが、Rewind など録音含めて全部記録する発想のツールもある――、が、これらは所詮録音以降の話である。
巻き込みと引き出し、そしてロールプレイ
最も重要なのは、その録音の対象となる「会話」の機会を増やすことだ。そして、会話の最中にさらに引き出させることだ。それぞれ （機会への）巻き込み、（さらなる情報の）引き出し と呼びたい。
巻き込みについては、ヒントは多い。OST（オープン・スペース・テクノロジー）のような形式的な、しかしカジュアルな対話会はよく使われているし、定期的にマンツーマンで喋る 1on1 もなんだかんだ寄与してきたはずだ。場所と雰囲気の重要性も再認識されていて、給湯室や喫煙室のようないわゆるマグネット・スペースの再構築は、オフィス環境として投資されている。あるいは Remotty や Teracy など小気味いいバーチャル・オフィスも増えてきた――と、人を場に巻き込むためのヒントは色々ある。これらを体系的にまとめたいところだ。特に、チャットであるので、気軽におしゃべりする場なんだよとの体裁と、それを使えるだけの物理的かつ精神的な余裕を確保したい。
引き出しについては、ブレストにて他者の意見を見ることであれこれ思いつくような、アレである。自分ひとりで熟考するだけでは限度があるので、他者の意見をダシにする。また人間なので、退屈よりは楽しい方がいい。非言語情報や雰囲気は重要だ。チャット・ストーミングもブレストと同様、発想法的なスタンスを取る――つまり誰でも何でも言っていいよ、だ。そうして出てきたものを見て（あるいは聞いて）、さらに思いつくことを言う。ブレストと同じだ。違うのはここからで、チャット・ストーミングでは人間は（ほぼ）喋るだけ だ。付箋を書いたり、整理したり、どこに貼るか迷ったりしなくてもいい。発言の文字起こし、あるいはそれ以降の加工や可視化は LLM に任せればいい。私たちのおしゃべりをいい感じに見せてくれるので、それを見て、さらに思いつくことを言えばいい――と、こういう世界観を目指したい。
もう一つ、あるといいのが、Remotism でも書いたが ロールプレイ だ。私たちは大体シャイだし、特別に慣れた相手でもなければさほど喋れない。喋るためには、ある種の仮面を被った方がいい。言うまでもないことだ。チャット・ストーミングでは、おそらくこのロールプレイも積極的に支援した方が良い。そうすることで、誰もが安全に、遠慮なく発言しまくれるはず。もちろん、常に同座してその場でリアルタイムに喋らないといけないわけではない。ひとりだけぽつんと誰にも混じらず独り言を言ってもいいし、同座せず前もって喋っておいてもいい。そういう立ち回りも、役割として用意しておけば、誰でも使い分けができて便利だろう。たぶん、使い分けなのだろうと思う。ライブラリやコマンドをつくって使いこなすように、いろいろなロールをつくって使いこなすといいのではないか。
障壁
最後に、障壁として厚そうなものを一つ挙げておく。
このような「チーム内で行うようなラフな取り組み」を、果たしてパートナーや顧客とできるかという点だ。（業界次第だろうが少なくとも SIer では）ブレストさえまともに行えない。行う発想がまずないし、あったとして、提案したとしても一蹴されるだろう。こういうかたい世界に、いかにしてチャット・ストーミングを持ち込むかも考えねばなるまい。
よくあるのはドッグフーディングだろう。つまり、まずは自分達で使うために自分達なりにチャット・ストーミングを整備し、良さそうなら次に懇意にしている or アーリー的な顧客やパートナーを巻き込む、というふうに広げていく。チャット・ストーミングは体験的な営みなので、自分達自らが実践できることは Must だろうと思う。
チャット・ストーミング単体だと伝えづらいなら、既存の体験の一部や延長として組み込むのがいいかもしれない。アジャイルの一種ですよ等。
収集
集める、というより集め続けられるようにする
DCPC から引き出すための「収集」
と書いた。
特に名前はつけていない。単にドキュメント、コード、その他各種ファイルや環境から情報を集めてくる、というだけの話だ。API があれば叩けばいいし、なければつくればいい。何らかのバッチ処理としてつくることもあるかもしれない。LLM の文脈でいうと、共通プロトコルとして MCP がデファクト・スタンダードになりつつあるから「MCP サーバーをつくれ」になるだろうか。ともかく、情報を集める手段を整えて、集めればいいだけだ。
AISI では（LLM に使える形で出された）情報が最重要となるから、この収集にもしっかり費やしたい。専任の担当者をつけて整備するくらいはしてもいい。ゲーム業界ではデザイナーとエンジニアを仲介するテクニカルアーティストの役割があるが、同様に、環境と LLM を仲介する収集屋さんがいてもいい。デザイナーの成果物を、エンジニアにも使えるよう変換してあげるのと同様に、環境の情報を、LLM が使えるようにしてあげる（変換は後述するとして、まずはそもそも 環境から情報を取れるようにする）イメージ。もっと言えば、情報を取り続けられるようにする。一回取り出すのにめちゃくちゃ時間かかります、ではダメだ。ユニットテストと同じで、必要なときに必要なだけ、短時間で実行したい。
仮に AISI が盛り上がってきたら、この手の役割は確実に必要になると思う。
集め方のアプローチ
DCPC から引き出すと書いたり、環境から情報を取ると書いたりしているが、どこからどう取ってくるかの全体像を整理しておこう。
情報源は主に以下四点に分かれる。
- 1: ファイルストレージ
- 2: オブジェクトストレージ
- 3: バージョン管理システム
- 4: 実機その他実環境
以下詳しく見ていく。
バージョン管理システムに置け
まずはストレージ系を見ていく。
ファイルストレージは一番わかりやすい。PC 上、共有フォルダ上、クラウドストレージ上などにファイルを置く形だ。SIer では最も多い形態だと思われる。状況によってはセキュリティやコストの関係でリモートアクセスしづらいか、できない（つまりは物理的に出向いたりディスクをやりとりしたりする）こともある。人間にとっては馴染み深く、使いやすいが、AISI においては逆で、収集しづらい。少なくとも収集する用のファイルストレージを別途つくって、そこに置かねばならない。それが許されない状況の場合、そもそも AISI はできない。
オブジェクトストレージは、ファイルストレージほど直感的ではないが、ファイルを保存する場所である。AWS の S3 がわかりやすい。AISI でも選択肢になる。収集先のストレージとしてはファイルストレージよりも使いやすいはずだし、大量に放り込めるが、都度転送や同期が必要となり、リアルタイム性はおそらく落ちる。また大量に保存できるがゆえに、あとで管理する際も苦労するだろう。機密情報が含まれているかもしれないファイルが、ゴミも含めて大量に放り込まれている……なんてことになりかねない。うまく設計・管理しなければ、あっという間に汚部屋化する。
※ちなみに RDB のようなデータベースは、本記事では対象外とする。AISI ではオーバースペックだと思う。またベクトルデータベースについては、RAG を使うのなら必須だろう。後述する。
バージョン管理システムは、≒Git と言ってもいいだろう。一般人お断りの、難解なシステムだが、開発現場では共通言語かつ標準言語だ。細かい履歴の記録、協業や分業、またプログラムから操作できるので各種連携もしやすい。AISI では、できるだけ情報源をこれにしたい。コードやスクリプトについては、すでにこれで管理するケースも多いだろうが、文書もそうしたいのである。この点は次の Markize でも述べる（一言で言うと Markdown で書け）。
つまり、情報源としては、基本的にバージョン管理システムを使え、となる。もちろん、すべての文書のマスターを置くことはできないだろうから、複製や変換などうまく作り込んで、少なくともバージョン管理システム側に同期して置くことになる。SI 脳だとデータベースをつくりたくなるかもしれないが、違う。余計な仕組みや自製は要らない。テキストベースの、自分達の成果物を管理する手段は、バージョン管理システムが最適である。Git をマスターせよ。Git をマスターにせよ。ベクトル化など別の形式がほしいなら、Git から取得してつくればいい。
もちろん、Office 文書をそのまま Git に詰め込むのは論外だ。この点は次の Markize で見ていく。
実環境から収集する
もう一つ、情報源として欠かせないのが実環境（以下 実機 ）だ。オンプレ・クラウドを問わず、すでに開発・構築した何らかのマシンと、そこに載せてるアプリがある。設定値も変えているだろう。純粋に新規するのでない限り、実機は避けては通れない。DCPC のとおり、コンフィグ（実機上の設定）とパラメーター（文書側に書いた設定）の二重管理からも逃げられない。実機があるからいいじゃないですか、実機だけ見てれば・変えればいいじゃないですかとはならず、「実機の状態がどうなっているかを記載した文書」も必要なのだ。つまり 実機の情報を取得して、文書の方に転記するという同期の作業 をしなくてはならない。
※正しい正しくないではなく、強制約開発ではそうする（実機ではなく文書側をマスターになる）という話。また、実機がいつでも触れられるものとは限らず、むしろ極めて限定的なタイミングでしか触れないからマスターにできないといった特殊な事情もありえる。
古典的には手作業であった。ウォーターフォール的で常に「設計する → そのとおりにつくる・変える」の順番だったので、同期は取れていた。近年では IaC も使われていて、「設計コードを書く → それを実行させてそのとおりにつくらせる・変えさせる」の形で同期を取れていた。無論、どちらも完璧にそのとおりにその順番でやってこそ機能するわけだが、現場がそうなっているとは限らない。
最悪手作業で同期するしかないが、そもそも労働力が少ないから AISI で効率化したいのである。かといって、いちいち IaC で作り直すわけにもいかない。
どうするかというと、「実環境から情報を収集する → それを文書におこす」をすればいい。文書レベルのフォーマットが難しければ、付録でもいい。文書からは「実機の設定はこれこれの付録として記載しています」のような体裁にすればいい。この点も次で述べる Markize が使える。
私はこのような営みを RIaC - Reverse Infrastructure as Code と呼んでいる。要は環境をリバースエンジニアリング（というよりは単に実機情報を収集）して、文書あるいはそれに近しいフォーマットで保存することで同期を取る。もちろん収集は手作業ではなく、プログラムにて自動でやらねばならないし、その仕組みがないなら仕組み整備から必要である。AWS を例にすると、SDK や CLI を使って、AWS 上の実機から取得する命令（Describe, List, Get など）を叩く。これらを駆使した取得ツールをつくって、仕組みとして継続的に稼働させるイメージ。
IaC ではコードから実機に反映しつつ、実機に反映した情報を手元でも持っている（同期している）。「コード」と「実機」を同期している。一方、RIaC では、実機から取得した情報を「文書あるいはそれに近しいフォーマット」に落とし込む。名前がないと不便なので、仮にレポートと呼ぼう。つまり RIaC は「実機」と「レポート」を同期する 。そして、AISI では、この「レポート」を文書成果物の一つとして扱ったり、LLM に渡したりする。
※技術的は別に新しくはない。すでに IaC においても、実機から情報取得して「コード」をつくる機能やツールはあったりする。RIaC では、つくるものが違う。RIaC では「コード」ではなく「レポート」をつくる。
Markize
Markize とは
Markize は造語だが、「Markdown 化」だとか「Markdown をデフォルトで扱う」といった意味である。名詞にすると Markization だ。モダナイゼーションならぬマーカイゼーション。
そう、イメージとしてはモダナイゼーションが近い。モダナイはオンプレの古いシステムを、クラウドの現代的なシステムに載せるために、あれこれ適応させている。同様の概念として、DX の前段で語られるデジタイゼーションやデジタライゼーションもある。字面はうっとうしいが、望ましいあり方に変換していこうね、そもそもそういうあり方をデフォにしていこうね、だ。その Markdown 版を扱いたい。
わかりづらければ Markdown First でもいい。
(おさらい) Markdown が重要な理由
AISI においては、情報は Markdown で書くべきである。なぜなら Markdown はコンピュータと人間のどちらにも通じるハイブリッドな言語として、よく使われているからだ。LLM が十分に学習している言語とも言える。自然言語でたとえるなら英語のようなものだし、何なら英語よりもさらに身近な言語（母国語）くらいの位置付けである。大胆に言えば、Markdown は LLM の母国語だ。逆に使わない理由がない。
※ちなみに LLM が最も得意とするデータ形式は、純粋なテキスト（プレーンテキスト）である。これも同様に、コンピュータの歴史上、プレーンテキストが最もよく使われているし、実際コンピュータとしても処理しやすいからだ。このプレーンテキストの表現形式として最も無難なのが Markdown である、との関係になる。
Markize は三点に大別できる
Markdown の重要性をおさらいしたところで、本題に入ろう。Markize の活動も多岐にわたるが、大別すると以下の三点となる。
- 1: 変換。既存のドキュメントを Markdown に変換する
- 2: 重用。そもそも最初から Markdown でドキュメントをつくるようにする
- 3: 両立。LLM ファーストな Markdown フォーマットをつくる。しかし一次情報として人間が読めるように、また改ざんなどにも耐えるようにする。双方のバランスを両立する
1: 変換
まずは変換のニーズが強い。すでに大量のドキュメントがあるだろうし、新しく書くにしても、強制約活動を今すぐ変えることなどできず、引き続き Office 文書で書くことになるからだ。しかし、LLM には Markdown が適している――となれば、変換するしかあるまい。
といっても 現実的には、そもそも変換をはさまず抽出で済ませている。すでに多くのサービスでは、生成 AI にOffice 文書含む文書を読ませて、処理できている。画像についても、OCR を使えば「画像中の文字列」を抽出できる。いずれにせよ、対象を解析した上で、（装飾やデザインではなく）情報の本体を取り出しているだけだ。
この 抽出アプローチの問題点は、抽出ロジックがシステムに組み込まれてしまう点 だ。LLM の利活用も、そのシステムの一機能として使うことしかできない。たとえば、あるクラウドストレージが、保存された文書を LLM に与えてあれこれ対話できるとしよう。この対話機能が使えるのは、当然ながらこのストレージを使っているときだけだ。つまり可搬性がない。SI として「このストレージを使え」と指示できるのならそれでもいいが、そうもいくまい。文書は様々な手段や場所から LLM に渡せた方がいい。なら、文書自体がプレーンテキストになっていればいいし、もちろん Markdown になっていればいい。つまりは Markdown 版もつくっておけばいい。
とはいえ、今後抽出処理がさらに洗練され、気軽に使えるようになってくると変換は要らなくなる。2025 年現在では、要らないとまでは言えないと思う。抽出処理は技術的に難しくはないが、処理にはそれなりに時間がかかるし、つくりこむコストも馬鹿にならない。無視できるほど気軽ではない。今後どうなるかはわからない。
2: 重用
と、このように、Markize を変換だけでカバーするのは少々心もとない。
心もとないと言えば、もう一つある。精度の問題だ。文書からの抽出や変換では、情報の精度に限度がある、文書には「構造」と「情報」があって、構造としては装飾、形式、あるいは目次や段落や箇条書きや意味的・文法的な構造もあるが、抽出や変換では構造はあまり取り出せない。また、情報すらも取り出せないことがある。たとえるなら虫食いのようなものだ。そもそも Office 文書や PDF を始め、文書全般は、あとから正確に取り出せるようにはできていない。何ならセキュリティのために取り出しにくくするケースもある。精度にはどうしても限界がある。もちろん、精度が微妙な情報を LLM に与えたところで、出てくる回答も微妙になりかねない。
Markdown が必要なことはわかってる。変換では精度が出ない――ならば発想を変えて、最初から文書を Markdown で書けばいい。これをここでは重用と呼びたい。Markdown を重用している。あるいは デフォルト・マークダウン とでも呼んだ方がわかりやすいか。
言い換えるなら、SI でつくる各種文書を Markdown でつくらねばならないといえる。豊富な表現力を持つ Office 文書ではなく、プレーンテキスト + かんたんな構造を書ける程度の Markdown で表現しなければならない。これが難しい。パラダイム・シフトと呼べるほどの転換を要するだろう。
突然だが、「仕事で一切 Excel と Word を使うな」と言われたら、どうだろうか。SIer の人は、SE はもちろん、他のオフィスワーカーでもできないのではないか。私たちは思っている以上に、Office レベルの表現力に頼っている。私はこのような人や状態を Visual Addict - 視覚的な中毒（者） と呼んでいる。豊富な表現力によるリッチな視覚情報に慣れきっていて、依存してしまっている。
さらに踏み込むが、私は SI では豊富な表現は要らないとさえ思う。SI におけるドキュメントとは情報の集まりであり、大胆に言えばリストやシートだ。情報を塊の単位でかためて、かつ並べる程度の表現力で事足りる。契約まわり（自然言語的に複雑）や定量的な管理・分析（数字の操作）はそうもいかないが、大半はそうではない。ただの情報の列挙にすぎないはずだ（情報と用語の量が多いだけで）。この程度であれば、Markdown でも表現しきれる。
見出しを使えば塊をつくれるし、階層化もできる。箇条書きを使えば列挙もできるし、リンクやコードも書ける。無論、Markdown はファイルでもあるので、ファイル単位で分けることもできる。
# Markdown 文法の例
# 大見出し
## 中見出し
### 小見出し
- 箇条書き
- aaa
- bbb
- ccc
段落段落段落段落段落段落段落段落段落段落
段落段落段落段落 [リンク](URL) 段落段落段落段落
デフォルト・マークダウンに従うと、文書を書くとは Markdown で情報を並べることにも等しい。Office 文書のように細かい見栄えに費やす必要はない。ただただ必要な情報を並べて、塊とその関係という形で構造化すればいいだけだ。文書はどうせ LLM に読ませるんだし、LLM は情報がどういう順番で与えられようが関係がない。AISI では、Markize は、LLM のための情報整備である。人間相手という発想は捨てていい。私達は LLM のために、情報を Markdown で並べるだけだ。
というとかんたんに聞こえるが、意味的に正しく表現し、かつ LLM にもそのとおりに読み取ってもらうには、ちゃんと塊とその関係をつくらないといけない。結局、目次を伴うような構造をつくることからは逃げられない。ただ、それでも Visual Addict ほど表現にこだわる必要はないし、こだわらなくても記述しきれるはずだ。
また、安易に複雑な図表や動画像を使うのではなく、Markdown で記述しきるためにどう本質的にシンプルに捉えるかという本質思考も求められる。もちろん、構成図などどう頑張っても Markdown では表現しきれないものもあるが。
私は Markdown もスキルの一種と捉えている。いきなりプログラムを書けないように、また普段書ける人でも初体験の TypeScript をいきなり書くことはできないように、デフォルト・マークダウンもいきなりこなせるものではない。単に Markdown の文法を覚えれば書けるというほど甘いものではなく、表現したい情報をどう Markdown に落とし込むか、特に塊とその関係をどう構造するかという部分で差が出る。スキルだと思う。よって、AISI をするなら、エンジニアは、Markdown を書く（というより Markdown で書く）スキルも鍛えないといけない。
そういうわけで、デフォルト・マークダウンと一言で言っても、ハードルは思っている以上に高い。
3: 両立
- 3: 両立。LLM ファーストな Markdown フォーマットをつくる。しかし一次情報として人間が読めるように、また改ざんなどにも耐えるようにもする。双方のバランスを両立する
すでに述べたとおり、SI は強制約活動であり、文書自体も成果物となる。しかし Markdown はプレーンテキストであり、成果物としての体裁がいささか悪い。主には三点ある:
- 保証面。ただのテキストなので改ざんが容易である。改ざんされていないことを示すには？
- 見栄え面。LLM に読んでもらうために情報を並べる形で書いているため、人間には読みにくい。特に Visual Addict は見向きもしない
- 読みやすさ面。文書を人間が読む際は、やはり豊富な表現力を使って視覚的に見やすくした方が読みやすい
また前項で述べたとおり、デフォルト・マークダウンが通用するような書き方（どんな情報をどう書いていくか）についても、体系やプラクティスがあった方がいいだろう。LLM 向けのテクニックとしてプロンプト・エンジニアリングはすでに知られているが、同様に、Markize 用のエンジニアリングがほしい。塊はこう書くといい、塊と塊はこうつなげるといい、パラメーターを表現するにはこの書き方が一番通じやすい――LLM 向けの、書き方の工学を整備できるはずだ。
まとめると、LLM向けの書き方と人間が利活用できる程度の体裁を両立したい。
まずは前者、LLM 向けの書き方について深堀りしたい。そもそものフォーカスは、LLM に文書を与えることである。抽象的に言えば文脈（コンテキスト）を与える。LLM に与えるものは二つあって、指示と文脈だ。この二つを質問文（プロンプト）の中に全部詰め込むわけである。そういうわけで、LLM 向けの書き方とは、SI に関する文書を文脈として記述するには、と言い換えても良い。不便なので名前を付けたいのだが、コンテキスト・エンジニアリング（Context Engineering） はどうだろう。プロンプトの書き方ではなく、コンテキストの書き方である。もっと言えば、AISI 用のコンテキスト・エンジニアリングと言える。詳しい中身には立ち入らないし、私もまだつくってはいないのだが、たとえば前述したとおり、塊を並べる世界観で各種概念と文法を定義するといいと思う。
次に、人間が利活用しやすい体裁の話だが、これは単に Markdown 文書から変換してつくればいい。すでに Markdown to HTML をしてウェブサイトやブログにしたり、to EPUB にして書籍にしたりする例は珍しくない。もちろん to PDF や to DOCX など従来形式の文書もつくれる。Markdown から他形式への変換は確立されているので、既存ツールを使うか、なくても自製できるはずだ。署名の付与も、筆者は未経験だが、出来ないなんてことはあるまい。
最も重要なのは Visual Addict に屈しない ことだろう。Markdown には見栄えや装飾の情報がないか、乏しいので、私たちが普段触れているリッチな文書の表現力は出せない。そんな表現など無いのだ、要らないのだという前提を受け入れなくてはならない。
というわけで、両立として行うことは、コンテキスト・エンジニアリング――特に AISI 向けの書き方を整備することと、人間向け利活用のために Markdown to XXXX への変換を適宜使うこと、その際 Visual Addict に屈さないことである。
継続的エンベディング（CE - Continuous Embeddings）
(前提) 埋め込みベクトルの重要性
LLM に動的に情報を与える手段は一つで、プロンプトだ。プロンプトの中に指示と文脈を書く。AISI の場合、文脈とはもちろん SI に関する情報であり、すでに述べたとおり文書で、特に Markdown で表現するのが良い。
問題はプロンプトのサイズが限られていることだ。たとえば上限 10 万文字だとして、文書群の文字量が 100 万文字の場合、全体の 1 割しか与えられない。実際は指示も入れないといけないから 1 割も入らない。では、この 1 割をどうやって抽出すればいいのか？との話になる。要は、LLM を使えば意味的な抽出が可能だが、この機能を使うためには、まずは LLM を使わず 1 割にまで抽出しておかねばならない。
※余談だが、プロンプトのサイズが大きくなれば済むかというと、そう単純でもないらしい。LLM のアルゴリズムの性質上、サイズが大きすぎると上手く理解されなくなるとか、単純に計算量が爆発して追いつかないなど課題も多いそう。というわけで、現時点では、全部プロンプトに突っ込む前段階でもまずは絞る、が正攻法となっている。
意味的な抽出は非常に難しい。単純なキーワード検索どころではない。どちらかと言えば自然言語処理の話になるし、最終的には機械学習の話になる。時間とマシンパワーを費やして、静的に学習させることになる。LLM はまさにそうやってつくられているし、こんなことは真似できやしない。できても時間とコストがかかる。だから静的に与えるのは諦めて、動的に与えるしかなくて、でも動的に与えるためのプロンプトはサイズが限られていて――との構図になっている。それでも、静的寄りのやり方をある程度は採用しなければならない。
結論を言うと、現時点では 埋め込みベクトル（Embeddings） が良いとされる。文章を数学的なベクトルに変換することで、文章の類似度を「ベクトルとして似ているかどうか」で計算できる。ベクトルと言えば向きと大きさを持つ「矢印」のようなものだが、埋め込みベクトルは、あらゆる文章を矢印に変換して空間上にマッピングする（埋め込む）イメージ。細かい解説は割愛するが、ともかく、これなら類似度ベースで意味的な抽出ができる。LLM も「次にくる言葉を推測する」AI で、類似度の高いものを出力しているようなものなので、埋め込みベクトルはいわば LLM の劣化版とでも言える。
つまり、100 万文字の文書群を埋め込みベクトルに変換しておくことで、任意の観点で意味的に 1 割を抽出できるようにしておくのだ。
ちなみに埋め込みベクトルを保存するデータベースはベクトルデータベースと呼ばれる。ベクターデータベースとかベクターストアと呼ぶこともある。専用のサービスや製品もある。生成 AI における RDB と言ってもいいくらい避けては通れない存在だと思う。
継続的に埋め込む
埋め込みベクトルが重要であれば、当然ながらこれを常時維持できた方がいい。この手の概念はすでにエンジニアリングに存在する。継続的デプロイ、継続的インテグレーション、継続的デリバリーといったものだ。従来、手作業で時間がかかっていたデプロイやインテグレーションやデリバリーを、変更があったら（あるいは特定のトリガー起点で）自動的に行わせるようにする。そのためにソースコードや設定ファイルを全部 Git に置くことで、自動化しやすいプレーンテキスト表現の徹底と、コミットしたら開始というコミットドリブンの概念を手に入れる。また、細かい手順も、IaC としてコードで書いてプログラムに処理させることで、手作業から解放させる――。
同じことを埋め込みにも適用するべきだろう。継続的埋め込み、または 継続的エンベディング（CE - Continuous Embeddings） と呼びたい。
技術的な詳細と現状は割愛する。私もてんで無知だが、まだこの概念が巷に出てないということは、それなりの技術的ハードルがあるのだろう。詳しい事例や研究があったら教えてほしい。
Markize と二つの CE
ここまでを整理すると、登場した概念は三つ。
- Markize
- 情報、特に文書や（RIaC における）レポートは Markdown で書け
- コンテキスト・エンジニアリング
- SI の文脈を Markdown で書くための書き方を整備せよ
- 継続的エンベディング
- 継続的に埋め込みを行える仕組みをつくれ
文書とレポートは Markdown で書いて保存する。特に、AISI に適した書き方があるはずなので、それを整備してそのとおりに書くとやりやすい。また、LLM に与えるプロンプトサイズには制限があって、埋め込みベクトルによる類似度ベースの絞り込みが必須だろうから、継続的に埋め込みベクトルをつくるようにもしておく。
デリファメーション
再び造語で申し訳ないが、デリファメーション（Delefirmation） とは委譲（デリゲーション, Delegation）と承認（コンファメーション, Confirmation）を指す。生成 AI では AI に仕事を任せて、人間はその結果をチェックしたり道中の承認を通したりするとの分担をする。このようなあり方を指す言葉がほしかったので便宜上定義した。
デリファメーションの捉え方に正解はないだろうが、私は以下のように整理した。
- AI アシスタントと AI エージェント
- デリゲーション・マネジメント
- デリファメーション・トランスフォーメーション
なお、AISI に特化した内容ではなく、生成 AI 利活用全般に当てはまると思う。つまりはソフトスキルだと捉えている。
AI アシスタントと AI エージェント
何よりもまずは LLM にどうやって頼るかが大事だ。
大別するとアシスタントとエージェントがあると思う。
アシスタントは現状でも多用されているもので、人間がメインで作業する前提で、適宜 LLM をツールとして使う。ChatGPT はわかりやすいが、コピペが面倒くさい。小難しくいうとシーム（継ぎ目）がある。シームレスにできれば良い――というわけで、Copilot、Cursor、Cline といったツールが盛り上がっている。コピペする手間なく、IDE 上で直にプロンプトを打ったり、コードも直に書き換えたりする。
このアシスタント方式も、まだまだシームレスであって、人間による承認が結構必要だ。どうせなら全部 AI に任せられないか――というわけで、Devin などのツールが出始めている。エンジニアの作業として各種コマンドを叩いてあれこれ更新したり、GitHub 含めシステムに情報を投げたり、更新したりといったこともあるわけだが、この辺も任せてしまうわけだ。いわゆる「AI エージェント」も、定義上は自律的にタスクを遂行する。人間は何も確認しないか、遂行結果をチェックするだけ。もはや承認はしていない。AI に任せて、その結果を見るだけだ。
LLM の利活用というと、（特に SI では）利活用したプログラムをシステムに組み込むことをイメージしがちだが、それだけではない。私たちエンジニアが普段の作業でも LLM を使って省力化する 部分も含む。というより、まさにここにフォーカスを当てている。当たり前だが、LLM を使ったシステムやソリューションをつくるのなら、自分達が使えねばなるまい。もっとも SIer は保険屋であり、その体裁を守れればシステムの品質や使い心地などどうでもいいということもできるが、だとしても顧客にお金を出してもらうための提案は必要だろう。LLM について、使用者の目線で深く理解していなければ提案は出せまい。
というわけで、改めて言うまでもないが、アシスタントとエージェントは利活用していくべきである。特にセキュリティやコンプライアンス上のリスクがあるからといって、迂闊に厳しくするのはあるあるだが、それでは利活用が進まない。AISI でも、いや AISI だからこそ、私たち自身が日頃から使っていかねばならない。
どこまで一般化できるかわからないが、LLM に限った話ではなく、SIer は「私たちエンジニア自身のツール」を軽視するきらいがある。エンジニア向けにわかりやすく言えば、Microsoft 365 程度のツールで満足しがちだ。Teams よりも Slack、バージョン管理の GitHub、また Issues、ノートの Notion、Wiki の Cosense など、一般的なビジネスマンではなく「エンジニアだからこそ」重宝するツールというものがあるのに、それを使わない。投資もしない。せっかく AI という盛り上がりが来ているので、これを期に、このツール軽視の風土にメスを入れていきたいものだ。
デリゲーション・マネジメント
要するに、AI に任せたことをちゃんと管理しよう、という話である。
個人的には以下があると思う。
- タスク管理
- モデル（プラン）の把握と使い分け
- プロンプト・エンジニアリング（LLM 相手のコミュニケーション術）
何よりもまずは タスク管理 だ。仮に AI に 30 のお願い事をしたとして、これら全部をどうフォローするかはあなた次第である。無論、こんなものを頭の中でカバーすることなどできないし、できるにしても馬鹿げているので、上手いことツールと方法論を使いたい。タスク管理の出番である。
タスク管理については、拙作で死ぬほどまとめたので、そちらをどうぞ。
思っているよりも広くて深くて、そのくせとっ散らかって誰も整備してない領域なので、見かねて整理した。参考にできそうなところを拾って、取り入れるといいだろう。別に難しいことは言ってなくて、皆が薄々わかっていることを改めて言語化して提示しているだけだ。そうそう、そういうのも使えるよね、などと思い出すのに使えると思う。
次に モデルの把握と使い分け も重要だろう。モデルと書いたが、プランでもいい。ChatGPT（OpenAI）でいうと、たとえば以下がある。
- 4o
- 4.1
- 4.1-mini
- 4.5
- o3
- o3-pro
それぞれ用途と性能とコストが違う。AISI に限らず、LLM の利活用とは LLM の API をばかすか叩いて呼び出しまくることと同義なので、コスト面は気にしないと死ぬ。クラウドの SI をしている人には言うまでもないが、従量課金的な世界なのだ。使い分けが面倒くさい、高そうだから使わない、ではなく、最適な使い分けをしていかなくてはならない。
最後に、プロンプト・エンジニアリング も依然として重要だ。プロンプトは LLM 向けのプロトコルとでも言える。日本には日本のコミュニケーション作法や言い方があるように、LLM 向けの作法もある。その辺を整理したのがまさにプロンプト・エンジニアリングであり、避けては通れない。エンジニアだけでなく、AISI に携わるすべての人間が必須のリテラシーとして身に付けねばなるまい。
抽象的に言えば、私たちは一エンジニア・一作業者であっても、多くの AI 部下を抱えるマネージャーにならざるをえなくなる。マネージャーとしてのコミュニケーション能力が必要なのだ。その共通言語がプロンプトであり、そんなプロンプトを上手くつくるための体系がプロンプト・エンジニアリングである。要は プロンプト・エンジニアリングを知らない人は（LLM 相手には）コミュ障になる。コミュ障にマネージャーは務まらない。
デリファメーション・トランスフォーメーション
造語の造語という最悪なことをしているが、名前がないから仕方がない。ご容赦いただきたい。この言葉が言っているのは、「委譲と承認という AI ありきの働き方へのシフトをせよ」「そのためにやり方・考え方・あり方を大きく変えることになるかもしれないが、キャッチアップしていけ」だ。
DX（デジタル・トランスフォーメーション）がまさにそうで、ソフトウェアの恩恵にあやかるためには、ソフトウェアの流儀に 私達が あわせて行かねばならない。スマホ？そんなもの知らないよ、ではなく、スマホを使うことを前提としたビジネスのやり方考え方あり方に変えていかねばならない。それができない会社は未だにアナログだろうし、会社ができていても顧客ができていなければ（顧客を変えていけてなければ）、同様に引っ張られて不便を被る。同じことが生成 AI についても言えるが、ただ「AI への変革」と言っても情報量がないので、もう少し具体的に、 デリファメーション（委譲と承認）へのトランスフォーメーション（変革） だと言っている。
端的に言えば、自分が 100% やっていたものを、50% だけで済むようにする（50 の数字は適当でいいがそれなりに大きい、たとえば半分以上）。それをあらゆる仕事やコミュニケーションに適用する。根本の考え方を、自分 100% → 自分 50% + AI 50% にシフトするのだ。これくらい大胆に身を置くことで、LLM の真価が嫌でもわかるようになる。何事も経験というし、仕事を身につける際もどっぷり浸からせると思うが、同じだ。ただそれを、一言でわかりやすく言うために、「委譲と承認」に注目して、それ前提の価値観に変わっていこうぜと表現しているだけだ。
と、口で言うは易し。実際には様々な転換が要求される。AI に関するツールが潤沢に使えることはもちろん、使いこなすための勉強、練習、試行をする時間や余裕（あるいはインセンティブ）も必要だし、そもそも「AI がつくった見慣れない成果物」にも慣れないといけない。自分の手足を動かすことに喜びを感じていた人は、AI の成果物を読んだり、AI に追加の指示を出したりするという「つまらない作業」に適応していかねばならない（戦国時代が終わって武士が用無しになる構図）。もちろん、自然言語を使うので、言語化や読み書きの能力も今以上に重要となる――などなど。
そして、こういった転換は、個人の努力やスキマ時間の学習程度でどうにかなるものではない。変革全般に言えることだが、破壊的なサポートが必須だと思う。たとえば以下のようなことだ。
- 投資。生成 AI を不自由なく使うための環境的・制度的な投資
- 教育。使うために必要なリテラシーの教育
- 適用。少しずつ既存の業務や製品に組み込んでいくことで、実務レベルでの利活用に慣れていくこと
- 登用。継続的なフルコミットとアウトプットを担える変人的人材を内外から登用して、任せることで社内の好奇と熱気を上げる
- 共有。社内 SNS などで全社員の利活用その他議論を活性化させ、社内を盛り上げる
変革というと、ボトムアップで社内政治も切り抜けて磨かれたものを指して「これが我が社の変革です！」などと言ったり、従来のかたい仕事と同様、予算や計画をつくらせて守らせたりしがちだが、違う。変革とは偶然であり、偶然を高確率かつ早期に起こすには、起きる確率を引き上げるしかない。破壊的と書いたが、そのレベルの大胆さがそもそものスタートラインだと思う。考えてもみてほしい。これだけ技術と方法論が揃っていて、オフィスワーク程度ならリモートくらい当たり前にできるはずなのに、いまだに出社だとか東京への一極集中だとかほざいているわけである。コロナが起きていなければ、今でもビフォーコロナが続いていたのだと思うとぞっとする。（行き過ぎて過激な思想になってもいけないが）変革の前提として、破壊的な要素が要ると私は思う。
スタートラインに立てるのなら、方法は問わない。カリスマ的なトップが暴君となって牽引してもいい（日本企業は文化的に難しい）し、全社員に機会と自由を渡して化学反応が起きるのを待ってもいい（やらかしが起きても全社員を邪魔しないための制度設計が文化的に難しい）し、出島戦略と呼ばれるが治外法権組織をつくって変人奇人才人たちに遊ばせてもいい（これもなんちゃって出島の域を越えるのが難しい）。
おわりに
AISI と題して、「生成 AI を用いて SI を変革するためには？」に対する一つの持論を書いた。
最大のインパクトは「LLM にいかに情報を渡すか」であり、そのためにできることを組み上げた。
具体的には、まず人間から情報を引き出すためのチャット・ストーミングや、既存の成果物や環境から収集するためのアプローチを整理した。次に、情報を LLM に渡すために、Markdown と埋込みベクトルが重要であることも取り上げた。最後に、LLM を使うとは委譲と承認へのシフトを意味し、価値観のレベルで変えていった方が良いことを述べた。
刺激や参考になれば幸いである。
p.s.
- これは一人の持論にすぎないし、あらゆる SI を捉えたものでもない。だから何だと言われればそれまでだが、それでも私は書きたかった。生成 AI の影響は大きく、SIer としても、ひとりのエンジニアとしても、また単なる一個人としても無視できるものではない。しかし、漠然と触れているだけでは不安も拭えない。必要なのは道標だろう。誰もつくってはくれないし、すでにあるものは遠すぎてピンと来ない。だからつくった。どれだけ使えるかはわからないし、すぐに役に立たなくなるかもしれないが、私はこの羅針盤を使って、生成 AI という名の嵐の吹き荒れる荒波を乗り越えていきたい。
- エビデンスなど証跡を残す部分や、実機に常に触れられないせい問題の打開には言及していない。宿題にしておこう。
Discussion