一部の作業が減り、実装速度だけで評価される仕事の条件が厳しくなる可能性は、否定できないと思う。ただし私は、エンジニアという人間が単純に「代替される人」と「高度人材」に二分されるというより、一つの職種に含まれていた作業の価値が組み替わっている、と見ている。
AIがコードや設計案を生成するようになっても、それを納品してよいか判断し、本番で問題が起きたときに原因を追い、次の失敗を防ぐ仕事は残る。生成が速くなったぶん、その仕事の重要性はむしろ高まる。
では、まだ長い経験を持たないジュニアは、どこでその判断を身につければよいのか。私は、いきなり最上流へ飛び級することではなく、「品質を引き受ける場所」から始めるのが一つの活路だと考えている。
経済産業省とIPAによる「ITエンジニアリング人材の育成に関するタスクフォース」の第2回会合に、「ローエンドエンジニアは代替され、新たな価値を創造する高度エンジニアが不足する」と記した資料が提出されている（IPAの開催資料一覧、松田委員提出資料）。これはタスクフォース全体の最終結論ではなく、情報サービス産業協会（JISA）の松田委員による提出資料に書かれた現状認識である。
「ローエンド」という語は、人を固定的な階層へ置くようにも読める。だが、実際に代替される単位は、まず人ではなく作業なのではないか。
仕様から定型的なコードを生成する。既存コードに似た修正を作る。テストのひな型やドキュメントの下書きを作る。こうした作業はAIによって速くなる。一方で、顧客が何を必要としているかを確かめ、曖昧な要求の扱いを決め、生成物を検証し、運用上の結果を引き受ける仕事まで、同じように消えるとは限らない。
二極化を「能力の低い人が不要になる」とだけ読むと、ジュニアに残された答えは、短期間で高度人材になることだけになる。しかし、そこには経験をどう獲得するかという問題が残る。
私は一介のWebアプリケーションエンジニアである。技術力がずば抜けて高いわけではないが、20年ほどかけて上流から下流まで一通り経験してきた。現在はビジネスアナリストやプロジェクトマネージャーとして、クライアントと要求・要件を整理しながら、自分または少人数のメンバーで設計、実装、テスト、運用まで行っている。
その開発では、要求整理や設計、実装、テストなどの進め方を再利用可能にしたAIスキルやハーネスを40以上作り、多くの工程をAI化・自動化している。オントロジー、ドメイン駆動開発、仕様駆動開発、テスト駆動開発が主な軸である。
個人がAIを使って複数の工程をつなげられるようになると、作業を細かく分けたり、人を増やしたりすることが、かえって連絡や認識合わせの負担になる場面がある。それでも、人が必要だと思う場面はなくならない。
AIの解釈が仕様からずれていないか。正常系だけを見て、異常系を落としていないか。本番環境で問題が起きたとき、どの情報から調べるか。顧客の言葉と実装上の概念が食い違ったとき、どちらをどう直すか。こうした判断には、対象への理解と、過去の失敗を含む経験が要る。
一部では、AI時代にはジュニアも一足飛びに最上流の仕事ができなければならない、と言われる。しかし、それは難しい要求だと思う。シニアが10年、20年かけ、失敗や障害対応を通じて得た判断を、短期間で身につけろと言っているようなものだからである。
AIを使えば、設計書らしいものや、動くコードを早く出せる。だが、生成できる成果物の水準と、その成果物について説明し、問題が起きたときに対処できる水準は別である。この点は「ジュニアに設計を任せる前に、自分で説明できるかを見る」でも扱った。
では、最上流へ飛び級しないなら、ジュニアはどこから始めればよいのか。私は次の五つを、一続きの経路として考えている。
最初の入口は、丹念にテストすることである。
AIスキルやハーネスを整えても、それだけで納品できる品質になるとは限らない。仕様の読み違い、抜け漏れ、既存機能への影響、画面間の不整合は起こる。人間の仕事は、AIが出したものを眺めて承認することではなく、何をもって完成とするかを確かめ、完成していない点を具体的に示すことである。
受入条件を満たしているか。正常系だけでなく、入力の欠落、権限の違い、外部サービスの失敗、同時実行などを考慮しているか。仕様の記述だけでは判断できないなら、推測でテスト結果を合わせるのではなく、上流の担当者に確認する。
これは、決められたテスト項目を消化するだけの仕事ではない。テストを通じて、「このシステムでは何が正しいのか」を明らかにする仕事である。仕様の曖昧さに気づいて問いを返すことは、すでに要求分析の入口に立っている。
次は、一度の確認で得た知識を再利用可能にする。
ユニットテスト、結合・APIテスト、E2Eテストを使えば、多くの確認を自動化できる。E2Eテストの操作を録画し、受入条件と照らして確認することもできる。AIに実行結果や画面を渡し、差異の候補を挙げさせることもできる。ただし、何を不具合とみなすか、どこまでを受け入れるかの判断は人間に残る。
価値があるのは、AIより速くテストコードを書くことではない。どの条件が成立すれば正しいといえるかを定め、発見した不具合が再発しない形で残すことである。
その過程で、同値分割、境界値分析、状態遷移、デシジョンテーブルといったテスト設計技法も役に立つ。異常系やセキュリティの観点を学ぶと、テストしやすい要件、設計、実装とは何かも見えてくる。テストは開発の最後に置かれた検査ではなく、上流へ遡って設計を学ぶための場所になる。
システムは、作って終わりではない。使われ始めてからが本番である。
運用中の不具合では、ユーザーがどの操作をし、システム内部で何が起きたかが、開発環境のようには見えない。ログ、データ、メトリクス、トレースなどから判断することになる。実装時から、障害が起きたときに必要な情報へ辿れるようにしておく必要がある。
ここでいう記録は、ユーザーの行動を無制限に保存することではない。プライバシー、セキュリティ、保存費用に配慮し、必要な情報だけを適切なログレベルで記録する。リクエストIDや処理IDを使って一連の処理を結び、個人情報や秘密情報を残さず、どの段階で失敗したかを追えるようにする。
本番の問題を調べると、設計時には見えていなかった現実に出会う。想定外の操作、データ量、通信の遅延、外部サービスの停止、運用手順との食い違いである。その一つひとつが、次の設計判断に使える経験になる。
自分が変更した箇所だけでなく、その変更がシステム全体のどこに位置するかを理解する。
主要なデータはどこから入り、どこへ流れるのか。重要な業務ルールは何か。外部システムとはどこで接続するのか。権限はどのように決まるのか。障害が起きたとき、どの利用者と業務に影響するのか。
既存のドキュメントだけでは足りなければ、コード、データベース、ログ、チケットなどから、AIを使って調査の下書きを作ることもできる。私の場合、未知の領域を扱うときは、少なくともユビキタス言語と主要な業務ロジックを整理したドメインモデルを作るようにしている。
目的は、何でも暗記している人になることではない。この人に聞けば、根拠となるコードや仕様へ辿って説明してくれる、という状態を作ることである。システムへの理解は、AIの提案がその場では動くだけのものか、既存の仕組みに適合するものかを判断する基準にもなる。
最後は、個別の失敗や工夫を、チーム全体が使える形へ変える。
テストで仕様の抜けが見つかったなら、その案件だけを直して終わらせない。要求定義の質問項目、受入条件の書き方、レビュー観点、AIへの指示、テスト生成の手順へ反映できないかを考える。運用でログ不足に困ったなら、実装やレビューの基準へ戻す。
開発チーム内でAIスキルやハーネスを共有しているなら、そこへ改善を提案する。まだ存在しないなら、小さなものを自分で作って試してもよい。ジュニアであっても、テストや運用で得た具体的な発見を持っている。その発見は、上流担当者やシニアが見落としている工程上の問題を明らかにすることがある。
ここまで来ると、ジュニアは作業の受け手だけではない。チームの失敗を減らし、次の開発を改善する主体になっている。
五つは、独立した生存戦略ではない。
テストすると、仕様の曖昧さに気づく。仕様を確認すると、業務とシステムへの理解が深まる。本番を意識すると、設計時に考えるべき失敗条件が増える。そこで得た知識を自動テストやAIスキルへ戻すと、次の開発の品質が上がる。
テストする
→ 仕様の曖昧さに気づく
→ システムと運用を理解する
→ 発見をテストと開発プロセスへ戻す
→ より上流の判断ができる範囲が広がる
この循環によって、納品できる品質を引き受ける範囲が少しずつ広がる。テスト担当のまま留まるという話ではない。テストを、仕様、設計、実装、運用をつなぐ学習の入口として使うという話である。
ただし、以上を「ジュニアが勤務時間外に努力して身につけるべきこと」で終わらせてはいけない。
シニアのレビューを受けられること。本番運用や障害対応を知る機会があること。担当範囲の外側を学ぶ時間があること。生成したコードの量やチケットの消化数だけでなく、検証、理解、判断、改善を評価すること。失敗が致命傷にならない範囲を設け、そこで判断を試せること。これらはチームや組織が用意する必要がある。
AIによって定型的な実装が減れば、かつてジュニアが経験を積んだ仕事も減る可能性がある。その一方で、経験を積む前のジュニアへ設計や採否の責任だけを渡しても、育成にはならない。AIが短縮するのは生成に必要な時間であって、判断を形成する経験まで自動的に短縮するわけではない。
ジュニアの活路を考えることは、個人の生存戦略だけを考えることではない。人が育つ工程を、AIを前提に作り直すことでもある。
AI時代に必要なのは、全員が短期間でシニアになることではない。自分が検証し、説明し、結果を引き受けられる範囲を、一つずつ広げていくことだと思う。
丹念なテスト、運用への関心、システム全体の理解、開発プロセスの改善は、一見すると地味である。しかし、これらはすべて、生成物を受け取る人から、何を採用するか判断できるエンジニアへ移っていくための経験になる。
AIが普及していく流れを止めることは難しい。現在はIT業界が早く影響を受けているが、いずれ多くの業種と職種でも、従来ジュニアが担ってきた定型的な仕事が圧縮される可能性がある。そのとき、シニアの経験をどうすれば早く、しかし責任だけを飛び級させずに獲得できるのかは、社会全体の課題になる。
私はこの問題を、AIに作業を委ねながら、人間が判断と責任を保持するための条件という観点から研究している。その一つが『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』である。
AIへ任せる作業が増えるほど、人間には何も残らないのではない。どこまで任せ、どこから自分が答えるのかという境界が、これまで以上に問われる。ジュニアが経験を積む場所も、その境界の上に作り直す必要がある。
]]>先に結論をずらしておく。任せたくなるのは、成長が早まったからではないことがある。実装を書いて慣れるより先に、設計を任されている。本稿は、ジュニアは自分で設計せよ、という推奨ではない。支援があれば頑張れる、という励ましでもない。任せることと、自分で説明できることを分けて見る、という仮説の整理である。
素材にするのは、ニューヨーク・タイムズのエンジニアリングマネージャによる観察である（Thanabalan, 2026）。比較研究ではなく、現場のメモである。一般化はしない。
AIの生成が速いと、チケットは前に進む。それらしい修正も、それらしい構成案も出る。本稿では、そのぶん、手で書き、壊し、戻りながら仕組みに慣れる機会が薄くなりうる、と読む。
人間の側に残るのは、出てきたものを読み、どこから疑うかを決め、障害のときに自分の判断を説明する仕事である。先に書いた「AIを使うことは、「読みさえできれば何とかなる」に似ている」で扱った問題でもある。AI に書かせても、提案を採るか退けるかを決める仕事は消えない。チームでは、生成が速くなったあとほど、設計を理解しないまま案を通していないかを確かめる必要がある。
Thanabalan は、判断が育ったかが表れる場面として大きな障害を挙げる。仕組みを自分で辿って最初に調べる場所を決めるか、AI ツールが示した警告だけを追うか、という対比である。記事中では、若手が AI の提案をすぐ実行し、後からシニアが仕組みの理解に基づいて方針を修正する。本稿は、この場面を、任せることと説明できることのずれとして読む。
対応は、次のように整理できる。
| 出力だけを見る場合 | 判断まで見る場合 | |
|---|---|---|
| 作業 | 生成、提案の取り込み | 提案を採るか退けるか、説明、どこから疑うか、どちらを取るか |
| 指標 | 出したコードの量、差分の大きさ | 学習、理解、判断 |
| 確認するもの | 通ったコード | そのコードを説明できるか、障害のときに調べ始められるか |
支援を緩めてよいのは、自分で答えられる範囲が増えたあとである。
出したコードが増えたことと、システムを引き受けられるようになったことは、同じではない。「AIを「増幅器」と呼ぶ前に、何を増幅するかを見る」と同じで、増えているのが速度なのか、検証済みの判断なのかを分けないと、増幅は常に良い話になる。ジュニアが大変なのは、作業量が増えたからだけではない。実装で慣れる前に、設計判断を求められるからである。
Thanabalan は AI の使い方を、学ぶ段階（tutor）、設計判断を自分で持ちながら複雑な作業に使う段階（copilot）、経験を積んだ人が AI を速いジュニアのように扱う段階（accelerator）の三つに分ける。学ぶ段階では、説明を求め、分かっていない箇所を記録する。メンターや同僚には、プロンプトではなく仕組みを尋ねる。次の段階では、複雑な生成を使いながら、設計の判断と例外の扱いは自分で引き受ける。経験を積んだ段階では、要件と方針を渡し、AI の提案のうち、とくに構成と長期の影響に危うい点がないかを疑う。これは人を役職や固定した段階に閉じ込める手順書ではない。判断が育つにつれて支援を緩め、成功の指標を、出した量から学習・理解・判断へ移すための目安である。
この読みが効くのは、任せることと、自分で説明できることを分ける、という一点である。設計を任されることと、設計について答えられることは、同じではない。支援を緩めるのは、レビューで問いに答え、自分が触った範囲を説明し、障害のときにどこから疑うかを自分で持てるときである。出した量が増えたときではない。
効かない範囲もある。
第一に、すべての現場でジュニアに早く設計を任せる、とは言えない。本稿が扱うのは、生成が日常になり、若手に早い段階から設計判断を求めるチームである。
第二に、設計判断を早く任せること自体を、そのジュニアが未熟だから、と決めつけてはいけない。シニアが教える時間や、出した量だけでなく学習・理解・判断を見る評価も、チーム側の条件である。これらが欠ければ、任せることと説明できることのずれは広がりうる。人のせいだけにすると、チームの作り方は見えなくなる。
第三に、本稿はソフトウェア教育の実証ではない。一編のマネージャ観察と、既存の語彙を重ねた整理である。三つの段階を導入手順として推奨しない。
『AIによる認知スキャフォールディングとアイデア発散傾向の構造化』が足場と呼ぶものは、一時的な支援である。成人と AI の対話が、考えを整理する負担をしばらく引き受ける。元になった Wood らの指導研究では、人の指導者が、一人では難しい部分を一時的に支え、自分でできるようになれば支援を外す。論文はこの考え方を成人と AI の対話へ広げ、考えの整理や下書きを AI に任せても、どこまで強く言うか、提案を採るか退けるかは人間が決める、と整理した。
Thanabalan の記事では、人間のメンターがペア作業やレビューの枠を持ち、AI ツールは学習を助ける役に置かれる。一方、論文では成人と AI の対話そのものを、その一時的な支援として扱う。近いのは、AI に出力させること自体を、理解や成長とみなさない点である。AI に生成を任せても、その提案を理解し、採るか退けるかを決める仕事まで消えるわけではない。決める仕事を人の側に置かないまま出力だけ増やせば、増えるのは、まだ引き受けられない提案である。
『地頭至上主義の系譜と認知資源の多元主義』の語彙で言えば、AI を使った事実だけで仕事の良し悪しは決まらない。問うべきなのは、その出力を検証し、仕事へ組み込み、結果を引き受けられるかである。慣れる前に設計を任せたことを、その人の能力の問題に読み替えると、教える時間や評価の仕方というチーム側の条件が見えなくなる。
『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』の語彙も、ここで使える。「外部化」は、ここでは作業を AI に任せることを指す。AI に任せてよいのは、その結果について人間が根拠を示し、誤りを見つけて直し、提案を採るか退けるかを決められる範囲だけである。根拠は頭の中だけにある必要はない。変更履歴や対話の記録を辿って示せれば足りる、というのが論文の条件である。Thanabalan が障害で見る「最初に調べる場所を自分で決めるか、警告だけを追うか」は、その試験の一つの場面である。記録を辿っても方針を説明できず、警告だけを追うなら、その範囲の設計判断まで任せられる状態ではない。調べ始めを暗記していることが条件なのではない。
先の「AIがコードを書く時代に、なぜ「お気に入りの言語」を持つのか」で扱ったように、個人には、AI の提案を判断する基準が要る。チームでは、その基準を学ぶ機会の整備が、設計判断を任せる時期に追いつかないことがある。
ジュニアが設計する時代だ、と読むと、先に任せれば育つ、になりやすい。だが本稿が記事から引くのは、任せただけでは、答えられる範囲は自動で増えない、という読みである。
支援は、読めて、検証できて、提案を採るか退けるか自分で決められるようになるまで残す枠である。先に任せただけでは、支援にはならない。出す速さが上がったときでもない。支援を緩めるのは、自分で答えられる範囲が増えたあとである。その前に外すと、残るのは設計の担当と、警告だけを追う手である。
]]>私は最近、むしろ逆なのではないかと考え始めた。
AIがコードを書く今だからこそ、自分の思考や品質感覚の基準点になる「お気に入りの言語」を持つ意味がある。そして組織にとっても、言語選択の重要性が消えるのではなく、選ぶ理由が変わっていくのではないか。
なお、私はGo言語の専門家ではない。複数言語を同じ条件で比較したわけでもなく、本稿はGoの優位性を主張する記事ではない。GoとAI駆動開発についての記事を読んだことをきっかけに、言語選択を考える軸が変わった、という実務家としての仮説を整理する。
ほんの数年前まで、新しいプログラミング言語を導入しようとすれば、まず学習コストが問題になった。
チームメンバーが文法や標準ライブラリを覚えるまで、生産性が下がる。レビューできる人が限られる。採用や引き継ぎが難しくなる。既存のCI/CD、監視、クラウド基盤に載せられるかも確認しなければならない。
そのため、別言語の採用は単なる技術上の好みではなく、組織としての大きな決断だった。言語やエコシステムに魅力があっても、「いま使っている言語で実現できるなら変えない」という判断には合理性があった。
この事情をAIが部分的に変えつつある。
未知の文法の説明、APIの使用例、既存コードからの変換、テストの生成、コンパイルエラーの修正を、AIが支援できる。新しい言語で最初の動くコードへ到達するまでの距離は、以前より短くなった。
ただし、言語導入のコストがなくなったわけではない。コストの重心が、「人間が書き方を覚えること」から、「生成物を検証し、本番で運用し、問題が起きたときに答えられること」へ移っている。
AIが大量のコードを書く環境では、プログラミング言語は人間が実装するための表現手段だけではない。AIの出力を制約し、誤りを機械へ返すための装置にもなる。
型検査、コンパイラ、フォーマッタ、静的解析、テストランナーが明確なフィードバックを返せれば、AIは「生成する→検査する→修正する」というループを回しやすい。人間も、すべての行を目視する代わりに、どの制約を通過したか、どのテストで振る舞いを確認したかを判断材料にできる。
これは、人間がコードを理解しなくてよいという意味ではない。理解の単位が、一行ごとの著作から、構造・振る舞い・失敗条件・採否へ移るということである。
コードの詳細を常に追わないのであれば、言語とツールチェーンが何を自動的に拒否し、何を見逃すかを知る必要は、むしろ大きくなる。
きっかけは、GoのプロダクトマネージャであるCameron Balahanと、Google CloudのRichard Seroterが2026年8月に公開した「Why Go is an Ideal Language for AI-Assisted Software Engineering」だった。
記事は変化を、次の小見出しで表現している。
“From Writing to Reviewing”
人間が手でコードを書く速さより、AIが生成したコードをレビューし、検証し、保守する能力が重要になる、という主張である。そのうえで記事は、Goの価値を文法の簡潔さだけに置かない。統一的な書式、テスト、依存関係管理、セキュリティ検査を標準ツールチェーンから利用できること、予測しやすいコードの形、互換性と長期保守性を、一つのソフトウェアエンジニアリング基盤として論じている。
特に印象に残ったのは、AIを単なるコード生成器ではなく、監督と制約を必要とする新しいチームメンバーとして捉えている点だった。コードの表現が揃い、コンパイラやテストが明確な結果を返せれば、AIは生成と自己修正を反復しやすく、人間は意図や異常を確認しやすくなる。私が言語を見る軸を考え直したのは、この「言語そのもの」から「人間とAIが共同作業するためのプラットフォーム」への視点の移動である。
Goには、コードを標準形式へ整える gofmt、パッケージ単位でテストを実行する go test、疑わしい構造を検査する go vet など、公式ツールチェーンの中に共通の入口がある。公式サイトも、主要クラウド事業者がGo向けAPIを提供していると案内している（Go command documentation、Add a test、Go for Cloud & Network Services）。
もっとも、これはGoの開発責任者らによる公式ブログ上の提案であり、複数言語を同条件で比較した独立評価ではない。記事中の強い優位性主張を、そのまま私自身の結論にはできない。私も「Goを採用すべきだ」と判断できるほどGoに習熟していない。ただし、そこで挙げられた性質は、AIとの開発ループを評価する観点の候補にはなる。
これからの言語選択では、「チームがすでに書けるか」に加えて、「AIの出力をどの程度、機械的かつ運用可能な形で検証できるか」が重要になるのではないか。
では、AIが複数の言語でコードを書けるなら、人間は特定の言語を深く学ばなくてもよいのだろうか。
私は、少なくとも一つは深く付き合う言語を持ったほうがよいのではないかと思う。
お気に入りの言語は、単なる嗜好ではない。設計の良し悪し、読みやすさ、例外処理、テスト可能性、抽象化の程度を判断するための基準点になる。一つの言語と深く付き合って得た感覚があれば、AIが別の言語で提示した設計についても、「なぜこの構造なのか」「どこで失敗するのか」を問いやすい。
AIが学習摩擦を減らしてくれるからこそ、どこかには意図的に摩擦を残す必要もある。すべてをAIに説明・生成・修正させていると、異常を感じ取るための物差しまで育たない可能性がある。お気に入りの言語を持つことは、自分が引き受けて理解する領域を一つ確保することでもある。
ただし、個人のお気に入りを、そのまま組織の標準にしてよいわけではない。組織の採用判断では、対象領域、既存資産、運用体制、人材市場、依存ライブラリ、セキュリティ、クラウドの対応を検討する必要がある。個人の「好き」は探究の入口になりうるが、採用の根拠は別に示さなければならない。
私はこれまで、AIに認知作業を任せることを、単なる効率化ではなく、外部化と人間の責任の再配置として考えてきた。
『AIによる認知スキャフォールディングとアイデア発散傾向の構造化』では、低い層の認知負荷をAIへ外部化しながら、主張の強さや採否を人間に残す実践を扱った。
『地頭至上主義の系譜と認知資源の多元主義』では、頭の中だけで処理したか、外部資源を使ったかによって成果の正当性を決めるのではなく、外部資源を検証し、統合し、その使用に責任を持てるかが重要だと論じた。
続く『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』では、AIへ外部化できる範囲を、人間が成果の根拠を示し、誤りを検出・訂正し、採否を決定できる範囲として整理した。
この枠組みで考えると、AI時代の言語選択も「AIがコードを書けるか」だけでは決まらない。
人間がその成果について答えられるように、言語とエコシステムが検証の足場を提供できるか。AIが生成したコードを、型、テスト、静的解析、実行証跡へ落とせるか。そして、ゲートが通ったという事実を、人間が理解して採用できるか。
プログラミング言語は、生成対象であると同時に、答え責任を支える設計資源になる。
AIによって、新しい言語を試す費用は下がる。小さなサービスや検証環境であれば、以前より気軽に比較できるだろう。複数言語で同じ仕様を実装させ、テスト、可読性、運用、クラウド対応を比べることもできる。
その意味では、「別言語の採用＝後戻りできない大決断」という感覚は弱まるかもしれない。
しかし、試しやすくなることと、本番採用の責任が軽くなることは同じではない。AIが移植を手伝ってくれても、障害対応、長期保守、依存関係、セキュリティ、撤退可能性への答えは必要である。
これから必要なのは、言語にこだわらないことではない。好みだけにも、過去の慣性だけにも閉じず、AIと人間が検証可能な形で仕事を進められる言語を選ぶことだと思う。
私はまだ、Goが自分のお気に入りの言語になるかどうかを知らない。だからこそ、専門家のように結論を語るのではなく、実際に小さな題材を作り、AIとの生成・検査・修正ループがどう変わるかを確かめてみたい。
AI時代の言語は、人間がコードを書くためだけでなく、AIが書くコードを制約し、人間がその結果に答えるために選ぶものになるのかもしれない。
]]>先に結論をずらしておく。願いは、生産性の話としてわかる。ただし揃える対象を、個人の書き方の巧拙に置くと、話の種類が変わる。形式は職能の試験ではなく、誰が根拠を示し、誤りを検出し、採否を決められるかの配置である。本稿は、特定の記法へ移せ、という提案ではない。一本化の願いが、宛先の制度を個人のスキルへ翻訳してしまう点を、仮説として整理する。
表計算やワープロで仕様や手順を書くと、セル結合、余白、印刷の見栄えが作業の本体になりやすい。内容は少ししか変わっていないのに、版を重ねるたびに見た目を直す。機械に読ませようとすると、書式の情報が先に増え、構造が見えにくい。
一方で、見出し・箇条書き・表がテキストとして残る書き方は、人間のレビューにも、エージェントへの依頼にも、履歴の比較にも乗りやすい。低い層の整形を外へ出しやすい、という意味で、先に書いた「AIを使うことは、「読みさえできれば何とかなる」に似ている」の外部化と同じ向きにある。
ここまでを、怠けや流行の話にすると、現場の痛みを見落とす。減らしたいのは、中身と関係の薄いレイアウト労働である。エンジニアが形式を揃えたいと思うとき、そこに能力の優越より、残業の置き場を動かしたい切実さがある、と読んだ方がよい。
対応は、次のように整理できる。
| 作業側が揃えたい形式 | 提出側が今答えている形式 | |
|---|---|---|
| 向いている相手 | 書く人、差分、生成AI | 承認する人、顧客、印刷と捺印 |
| 軽くなりやすい工程 | 下書き、再生成、機械への入力 | 目視、コメント、既存のテンプレート |
| 重くなりやすい工程 | 提出用への変換、説明、差し戻し | 見た目の調整、版の管理 |
| 失敗の見え方 | 構造が壊れる、変換がずれる | レイアウトが崩れる、宛先が読めない |
作業側の生産性が上がることと、組織の残業が減ることは、同じではない。形式を一つにすると、片方の工程は軽くなる。もう片方は、変換と説明に移ることがある。負担は消えたのではなく、置き場が変わった、と見る方が正確である。
「読みさえできれば」で書いた条件と、ここは同じ線にある。読めて、検証できて、採否を引き受けられるとき、形式の外部化は足場になる。宛先が読めない形式へ一方的に揃えると、作業は速く見えても、通した理由をあとから答えられない。
揃えたい願いは、しばしば宛先を動かせない。提出物のテンプレート、承認の慣習、顧客のツールは、個人の好みでは変わらない。変わらないものを前にすると、残る操作は一つになりやすい。書けない人、使わない人を、遅れている側へ置くことである。
『地頭至上主義の系譜と認知資源の多元主義』で扱ったのも、この操作に近い。規範の存在は、誰かの信条表明ではなく、観察可能な排除効果に置いた。その一つが、構造的問題を個人の能力に読み替える言説である。受験論では、努力できる条件の不平等が、がんばらなかったからだ、という自己責任に翻訳される。認知労働では、過負荷が個人の対処能力の問題として語り直される。
ドキュメント形式の論争でも、同じ翻訳が起きうる。残業の原因が、提出先の制度にあるのに、個人の記法スキルの不足として語られる。だれでも覚えられる、と言いながら、覚えられないことを職能の欠如とみなす。条件が揃っていないことを、習得の失敗として見せる。極性は、論文の典型例と逆である。あちらは外部化を不正視する。こちらは、特定の外部形式を身につけていないことを不正視する。操作は同じである。
第6章の警告も、ここに来る。「道具で自己防衛しろ」は、構造を個人の対処へ押し戻す言説の再生産になりうる。全員が作業用の記法を覚えても、正本の宛先が提出用のままなら、レイアウト労働は消えない。移るだけである。
この読みが効くのは、形式を能力の門番にしない、という一点である。正当な外部資源は一つに固定できない。表計算もワープロも、すでに誰かにとって答えられる形として正当化されている。作業用の構造化テキストも、書く側と機械にとっては同じである。どちらかが普遍的スキルなのではない。宛先が違う。
効かない範囲もある。
第一に、見た目調整の労働が常に無駄だ、とは言えない。印刷、契約、現場の掲示のように、見た目自体が成果物である仕事がある。その工程を「機械に渡せ」と切り捨てると、別の答え責任を捨てることになる。
第二に、作業用の形式へ寄せれば検証可能になる、わけではない。見出しが付いただけの曖昧な文書は、機械にも人間にも切れ目を渡さない。形式は中身を良くする魔法ではない。先の「AIを「増幅器」と呼ぶ前に、何を増幅するかを見る」と同じで、入力の質が残る。
第三に、本稿は現場の文書を調査した報告ではない。一本化の願いと、個人化の言説が重なる点を、既存の語彙で読んだ整理である。特定の論争の当事者を裁く材料にはしない。
サイト名の「認知の足場」は、一つのファイル形式を勝たせる枠ではない。低い層の負荷を外へ置き、人間が判断できる位置に立つための枠である。
『AIによる認知スキャフォールディングとアイデア発散傾向の構造化』で扱った分業は、ここでも使える。整形と下書きは外へ出してよい。主張の強さと採否は、人間に残す。記法は、その枠になりうる。合格証にはならない。
『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』の境界は、正本と提出物を分ける理由になる。外部化できるのは、人間が根拠を示し、誤りを検出し、採否を決められる範囲に限る。作業用のテキストへ変換することは、パースの外部化である。変換結果を人間が検出・訂正できないなら、外部化ではなく放棄である。提出用へ戻す変換も、同じである。
だから欲しいものは、記法の一本化というより、AIが追えて、人間が採否できる正本である。それが作業用の構造化テキストである現場は多い。提出物が表計算やワープロである現場も多い。両方を認めると、願いは「全部を一つの形式にしろ」ではなく、「正本と提出物を分け、変換の誤りを人間が引き受ける」になる。残業が減るかは、その変換と検証を工程として数えられるかに依存する。数えなければ、負担は個人の習熟へ戻る。
形式を揃えたくなるのは、レイアウト労働と、機械への渡しにくさが実在するからである。その願いを、書けない人の問題にすると、制度は見えなくなる。
揃える対象は、個人の記法ではない。誰が、どの工程で、答えられるかである。作業の正本と、提出の写しが違うことは、失敗ではない。写しを正本と取り違えること、変換を検証しないこと、形式を職能の門番にすることの方が、壊れ方として大きい。
足場になるのは、読めて、検証できて、採否を引き受けられる配置のときである。形式が勝ったときは、足場ではない。
]]>しかし、文章が流暢であることと、論文として検証可能であることは同じではない。引用した論文を本当に読んだのか。数字の出所を再確認できるか。反対説を見落としていないか。AIが提案した結論を、人間が根拠とともに説明できるか。
私が公開している「Scholarly Agent Skills」は、この問題を「もっと性能の高いAIを使うこと」ではなく、研究と執筆の工程を設計することで扱おうとするオープンソースのスキル・ルール・検査ツール集である。
一言で表すなら、ソフトウェア開発の品質規範を論文執筆へ移植する試みだ。
このリポジトリの副題は、Thesis-Driven Developmentである。
ソフトウェア開発では、要求を定義し、概念をモデル化し、テストを書き、変更をレビューし、リリース前に品質ゲートを通す。複雑なシステムを、実装者の記憶と注意力だけに頼って作ることはしない。
ところがAIを使った論文執筆では、「テーマを渡して本文を生成する」という一回の対話に、研究計画、概念定義、文献調査、引用確認、反論検討、文章化をまとめて押し込んでしまいがちである。その結果、もっともらしい文章はできても、どの主張がどの資料に支えられているか分からなくなる。
Scholarly Agent Skillsが目指すのは、優れた一つのプロンプトではない。研究を複数の工程と成果物に分け、AIと人間がどこで何を確認したかをリポジトリへ残すことである。
中心にあるのは、次の対応関係である。
| ソフトウェア開発 | 研究・論文執筆への読み替え |
|---|---|
| 要求定義 | 研究問い、想定読者、完成条件を先に決める |
| DDD・ユビキタス言語 | 中核概念を定義し、論文内の意味を揃える |
| 仕様ギャップ分析 | 先行研究の到達点と自説の差分を明示する |
| TDD | 本文の前に想定反論と反例を書く |
| 不変条件監査 | 主張と一次資料の対応をゲート判定する |
| 静的解析 | 引用、用語、章番号、内部記号の露出を検査する |
| リリースゲート | 投稿前のWARNとFAILを著者が仕分ける |
| セッションハンドオーバー | 長期執筆の文脈と未解決事項を次回へ残す |
たとえばcounter-argument-tddでは、節を書き始める前に、査読者が提起しそうな反論を列挙する。TDDで最初に失敗するテストを書くように、まだ防御できていない主張を先に可視化する。その反論を乗り越える本文を書き、最後に論理と文体を整理する。
scholarly-concept-modelingでは、DDDのユビキタス言語に相当する概念インベントリを作る。同じ用語を章ごとに違う意味で使ったり、近い概念を無意識に混同したりすることを防ぐ。
開発手法の用語を論文本文へ持ち込むことが目的ではない。これらは内部の設計工程であり、公開原稿には通常の学術的な文章だけを残す。
このプロジェクトは、概ね四つの層で構成される。
ルールは、個別の作業を超えて常に守る制約である。
代表例が「ファクト・グラウンディングルール」である。このルールでは、LLMの記憶や検索結果のスニペットだけを根拠に、学術文献の内容、統計値、固有の事実を本文へ書かない。
文献検索は候補を見つけるDiscoveryにすぎない。論文の内容を引用するには、利用権を確認したPDFやオープンアクセス全文を取得して構造化するか、入手できない資料ならページ番号付きの手動ノートを作る。統計値は公式資料やAPIから取得し、原数値と算式を残す。
つまり「AIが知っている」から「リポジトリ内の資料で再確認できる」へ、根拠の状態を変える。
スキルは、発動する場面、前提、手順、成果物を定義する。
2026年8月27日時点で、日本語版と英語版にそれぞれ23スキルがある。ただし、最初からすべてを使う必要はない。基本的な流れは次のとおりである。
research-plan-workshopで研究問いを一文にするscholarly-concept-modelingで中核概念を定義するliterature-searchで候補を探すsource-criticism-gateで情報源を評価するpdf-paper-ingestionで一次資料を実体化するliterature-gap-analysisで先行研究との差分を整理するcounter-argument-tddで反論を先に置くclaim-evidence-gateとcitation-traceability-auditで主張と出典を監査するpre-submission-triageで残った警告を著者が判断する全体像は日本語版スキルカタログにまとめている。
LLMによるレビューは柔軟だが、同じ入力に常に同じ判定を返すとは限らない。そこで、機械的に検出できる問題はPythonスクリプトへ分離している。
たとえば、本文中の根拠不明な数値候補、引用と文献ノートの不一致、用語の表記揺れ、章番号の重複、内部管理コードの本文露出、センシティブな絶対表現などを検査する。原稿のMarkdown統合、HTML・PDF変換、文献検索、PDF取り込み、PIIマスキングを支援するスクリプトも含む。
現在は25本のPythonスクリプトと23のテストモジュールがあり、GitHub Actionsとローカルのpre-push gateで、ユニットテストとスキル定義の整合性検査を実行する。本稿執筆時点のローカル検証では157件のユニットテストが通過し、日英46個のスキル定義も検査を通過した。ただし、これは将来の研究成果や生成物の正しさを保証する数字ではなく、リポジトリ自身の回帰検査の状態を示すものである。
AIとの会話は便利だが、そのままでは長期研究の正本になりにくい。そこで成果物を、次の五分類で管理する。
docs/<paper-id>/
├── manuscript/ # 完成原稿・HTML・PDF
├── chapters/ # 章ごとの本文
├── design/ # 研究計画・概念・反論・ゲート記録
├── literature/ # 文献マトリクス・論文ノート・原本
└── data/ # 統計・集計・一次データ
AIとのチャットが途切れても、研究問い、採用した定義、確認済み文献、棄却した提案、残っている警告をファイルから復元できる。Gitの差分は、論文がどう変わったかだけでなく、判断の過程を後から確認する手がかりにもなる。
品質を厳しくすると、今度は工程が重くなり、着手できなくなる危険がある。そこで全スキルに、認知スキャフォールディング原則を適用している。
論文執筆の支援で、最初に十個の質問へ答えるよう求めても、認知負荷をAIへ外部化したことにはならない。AI側が散らばった思考を保持し、人間が今決めるべき一点だけを提示する必要がある。
ここには、速度と厳密さを両立させるための設計上の緊張がある。自由な着想は止めずに外へ置く。しかし、本文へ入れる段階では根拠を要求する。生成を許す場所と、検証なしに通過させない場所を分ける。
仮にAIが、本文へ「先行研究ではこの傾向が広く確認されている」と書いたとする。
通常の対話なら、そのまま文章を整えて次へ進めてしまうかもしれない。このワークフローでは、次のように戻る。
ここでAIは、文章の生成、候補探索、資料の構造化、反論候補の提示を担当できる。しかし、どの表現を本文へ残すかは著者が決める。
リポジトリはMIT Licenseで公開している。共同研究や複数環境で再現しやすい方法は、論文リポジトリへGit submoduleとして追加する方法である。
git submodule add https://github.com/hideshi/scholarly-agent-skills.git .scholarly-agent-skills
python3 .scholarly-agent-skills/scripts/setup_submodule.py --lang ja
手元の複数プロジェクトで同じ最新版を参照したい場合は、シンボリックリンク方式も使える。詳しい手順はREADMEに記載している。
最初の一週間で23スキルすべてを覚える必要はない。まず研究問いを一文にし、数字や文献を本文へ書く前に根拠ファイルを置き、一章できたら一つのゲートを回す。それだけでも、「AIとの会話」から「再確認できる研究工程」へ移行し始められる。
Scholarly Agent Skillsは、論文の正確性、網羅性、学術倫理、査読通過、投稿規定への適合を保証しない。品質ゲートにも誤検出と見落としがありうる。
インタビューやアンケートの倫理審査、個人情報の適法な取り扱い、PDFの取得・翻訳・再配布に必要な権利、外部APIの利用規約は、利用者が確認しなければならない。PIIマスキングやAI Ignoreは支援機能であって、十分な匿名化を認証するものではない。
提出先のAI利用方針やプレプリント規定も変わる。submission-venue-advisorは確認項目を整理するが、投稿してよいとは断定しない。詳細はDISCLAIMERに記載している。
最終責任が人間に残るからこそ、このプロジェクトは、人間の注意力だけに責任を背負わせない仕組みを作ろうとしている。
このプロジェクトは、完成した理論から一度に設計したものではない。私自身がAIと論文を書く過程で、文献の原本が保存されていない、内部用の記号が本文へ露出する、章番号の挿入が崩れる、古い文脈へ復帰できない、といった摩擦を経験し、その再発を防ぐルール、スキル、テストへ戻しながら発展させてきた。
『AIによる認知スキャフォールディングとアイデア発散傾向の構造化』では、AIへ低い層の認知負荷を外部化しつつ、主張の強さ、採否、最終責任を人間に残す分業を扱った。
『地頭至上主義の系譜と認知資源の多元主義』では、外部資源を使ったかどうかではなく、その出力を検証し、統合し、使用に責任を持てるかを問う必要があると論じた。
『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』では、人間が根拠を示し、誤りを検出・訂正し、採否を決定できる範囲を、外部化の一つの境界として整理した。
Scholarly Agent Skillsは、これらの問題意識を日々の作業へ落とす参照実装である。ただし、これらの論文と実装は、一般的な効果を実証したものではない。現時点では、著者自身の実践から生まれた設計と存在例として公開している。
AI活用の議論は、どのモデルを選ぶか、どんなプロンプトを書くかに集中しやすい。しかし、組織で継続して使うなら、より重要なのは、入力をどう管理し、出力をどこで検査し、誰が採否を決め、証拠をどう残すかである。
これは論文執筆だけの問題ではない。調査報告書、要件定義、設計文書、監査資料など、根拠と説明責任が求められる認知作業にも共通する。
Scholarly Agent Skillsは、その中でも論文執筆を対象に、AIとの協働を工程として設計した一つの実装である。AIを導入することと、AIが組織の品質基準の中で働けることの間には距離がある。その距離を、ルール、スキル、検査、成果物で埋めていきたい。
リポジトリはGitHubで公開している。試して見つかった摩擦や改善案は、IssueやPull Requestで共有してもらえるとうれしい。
また、論文に限らず、AIを要求定義、調査、設計、レビューへ組み込みながら、組織として検証可能な工程へ整えることに関心がある。AI活用プロセスや品質ゲートの設計について相談があれば、X（@hdsh0428）から連絡してほしい。
]]>手で漢字を書けなくても、画面上の候補を見て正しい字を選べれば、文書は出せる。AIも、最初から全文を自分で書かなくても、出てきた文やコードを読んで採否できれば、仕事は前へ進む。
ただし、似ているからといって、楽になった、で終わらせる話ではない。漢字変換が残したものは「書かなくてよいこと」ではなく、「読むことで選ぶこと」だった。AIも同じで、残るのは生成ではなく、読んで引き受けることだと思う。
手書きの時代、漢字は思い出す必要があった。画数、部首、送りがな。書けない字は、辞書を引くか、別の言い回しに逃げるしかなかった。
PCの日本語入力は、この負担の置き場を変えた。読みを打ち、変換候補を見て、意図した漢字を選ぶ。スマホのフリック入力も、基本は同じである。手が字形を再現しなくても、目が字形を識別できれば、文章は成立する。
その結果、読めるのに書けない字が増えた、という感覚を持つ人は少なくない。これは能力が消えた、というより、日常の作業が「想起して書く」から「候補を見て選ぶ」へ移った、ということだろう。
ここで残った技能は、入力そのものではない。候補の中から、意味の通る字を見抜く力である。「せいかい」が「正解」なのか「盛会」なのかは、文脈を読んで決める。読めなければ、変換は便利ではなく、誤りの量産装置になる。
生成AIの使い方も、この形に近い。
テーマを渡す。下書きが出る。コードが出る。要約が出る。人間は、それを読んで直すか、捨てるか、採用する。最初の一文を空白から書く手数は減る。残るのは、出てきたものが自分の意図と、使える根拠に耐えるかの判断である。
これは、プログラミングでも文章でも起きている。先に書いた「AIがコードを書く時代に、なぜ「お気に入りの言語」を持つのか」でも触れたように、作業の重心は書く速さから、レビューと検証へ移りつつある。
漢字変換との対応で言えば、次のように整理できる。
| 日本語入力 | AI利用 |
|---|---|
| 読みを打つ | 依頼と制約を渡す |
| 変換候補が出る | 文・コード・要約が出る |
| 文脈を読んで選ぶ | 根拠と失敗条件を読んで採否する |
| 誤変換を見逃すと意味が壊れる | 流暢な誤りを見逃すと成果が壊れる |
「読みさえできれば何とかなる」は、怠けの推奨ではない。手が覚える負担を機械へ渡したあと、目と判断が残る、という観察である。
この比喩が効くのは、生産の細部を外部化しても、識別は残る、という構造である。
漢字変換は、書字の想起を外部化する。AIは、下書きの生成を外部化する。どちらも、人間が最初の形を全部手で作らなくてよくなる。代わりに、候補を見て、自分の責任で残すものが決まる。
しかし、決定的に違う点がある。
漢字の変換候補は、辞書という閉じた集合から来る。候補は有限で、多くは実在する語である。誤りは、主に「別の正しい語を選んでしまうこと」である。文脈が分かれば、誤りに気づきやすい。
AIの出力は、閉じた辞書ではない。存在しない引用、それらしい型、通るはずのない推論を、通る文章として出せる。誤りは、語の取り違えではなく、根拠のない完成品に見えることがある。読めるだけでは足りず、「これは何を根拠に言っているか」まで読めなければならない。
だから、AI利用を「読みさえできれば何とかなる」に重ねるなら、その「読み」は、漢字の識別より一段重い。流暢さを読むのではなく、壊れ方を読む必要がある。
漢字変換が便利なのは、読める人にとってである。読めない人が変換を重ねても、誤変換の山ができる。機械は、意図を代わりに持ってはくれない。
AIも同じである。出力を評価できない状態で生成だけを増やすと、作業は速く見えるが、採否の根拠が残らない。あとから「なぜこれを採用したのか」と問われても、答えられない。
『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』で整理したのは、まさにこの境界である。外部化できるのは、人間が根拠を示し、誤りを検出し、採否を決められる範囲に限る。読めないものを、読めるふりして通すことは、外部化ではなく放棄である。
『地頭至上主義の系譜と認知資源の多元主義』の立場から言えば、頭の中だけで書いたか、機械を使ったかは、正当性の基準にならない。使った出力を検証し、統合し、その使用に責任を持てるかが残る。PCで漢字を選んだことも、AIに下書きを出させたことも、そのあとの引き受け方で決まる。
ここでも、漢字の話は警告になる。
書けなくても読める、という状態は、日常の入力では足りることが多い。しかし、初めて見る語、専門用語、固有名、微妙な違いでは、書けた経験がある人のほうが、候補の異常に気づきやすい。読む力は、書いた経験から育つ面がある。
AIでも同じことが起きると思う。すべてを生成に任せ、自分では一文も、一行も引き受けないでいると、異常を感じる物差しが育たない。お気に入りの言語を一つ深く使う、という先の記事の主張も、ここに接続する。書く手数を減らすほど、どこかには、自分が書いて読める領域を残す必要がある。
『AIによる認知スキャフォールディングとアイデア発散傾向の構造化』で扱ったのも、低い層の負荷を外へ出しつつ、主張の強さと採否は人間に残す、という分業である。スキャフォールドは、人間を不要にするためではなく、人間が判断できる位置に立つための枠である。
「読みさえできれば何とかなる」は、条件付きの文である。
日本語入力では、読み、文脈、候補の識別がある。それが揃って、初めて書字の外部化が足場になる。AIでは、依頼の出し方、出力の読み方、検証の手段、採否の記録がある。それが揃って、初めて生成の外部化が足場になる。
何とかなるのは、読める人が、読んだ結果に答えるときである。読めないまま通すなら、PCもスマホもAIも、同じように誤りの増幅器になる。
AIを使うことは、書くことから解放されることではない。書く手数を機械へ渡したあと、読む責任が残ることである。その意味で、日本人にとって馴染みのある変化の延長にある。馴染みがあるからこそ、楽になったと誤解しやすい。残すべきなのは、手の記憶ではなく、目と判断である。
]]>先に書いた「AIを使うことは、「読みさえできれば何とかなる」に似ている」では、同じ語を別の向きで使った。読めないまま通すなら、PCもスマホもAIも、誤りの増幅器になる、と書いた。
一方は成果の拡大、他方は失敗の拡大である。語が同じだから、同じ現象を指しているわけではない。増幅器は足場の別名ではなく、入力を大きくする装置である。何を入力するかで、足場の隣にも、誤りの増幅器にもなる。
本稿は、増幅器という語を捨てる提案ではない。肯定用法を否定するのでもない。何を増幅しているかを見ないと、楽になった話と、壊れ方が速くなった話が、一つの標語に潰れる、という整理である。
音響の増幅器は、信号も雑音も大きくする。良い演奏を大きくすることも、歪みを大きくすることもある。装置の善意は、入力の中身を選ばない。
AIの比喩としての増幅器も、これに近い。速く、多く、それらしい形で出す。入力が、検証可能な作業と、引き受ける判断であれば、到達範囲は広がる。入力が、未検証の生成と、採否のない通過であれば、流暢な誤りが広がる。
能力が増えたように見えることと、成果の根拠が増えたことは、同じではない。増えているのが速度なのか、検証済みの判断なのか、通った文章の量なのかを分けないと、増幅器は常に良い話になる。
ここで残る負担は、装置を買うことではない。何を入力し、何が大きくなったかを見ることである。手数は減る。見る対象は、むしろ増える。
対応は、次のように整理できる。
| よく使われる増幅器 | 誤りの増幅器 | |
|---|---|---|
| 入力 | 判断できる作業、制約、検証の手段 | 未検証の生成、読めない出力の通過 |
| 増えるもの | 到達範囲、試作の回数、下書きの速度 | 流暢な誤り、根拠のない完成品 |
| 人間の位置 | 採否できる場所に立つ | 通した理由を後から答えられない |
| 装置の役割 | 足場の隣（低い層の負荷を外へ出す） | 放棄の加速 |
肯定用法が間違っている、とは思わない。手が届く範囲が広がる感覚は、実務でも起きる。問題は、その感覚だけを残して、入力側を見なくなることである。
「読みさえできれば」で書いた条件と、ここは同じ線にある。読めて、検証できて、採否を引き受けられるとき、外部化は足場になる。それが無いとき、同じ外部化は誤りの増幅器になる。増幅器という語が二つあるのではなく、条件の有無で、同じ装置の帰結が分かれる。
この比喩が効くのは、装置が入力を大きくする、という一点である。善意も悪意もなく、渡したものの振幅を上げる。だからこそ、何を渡すかが残る。
ただし、音響の増幅器とAIは同じではない。
音響では、入力波形と出力波形の対応が比較的はっきりしている。歪みがあっても、何が大きくなったかを追いやすい。AIの出力は、入力の拡大というより、別の完成品に見えることがある。増えているのが元の判断なのか、それらしい補完なのかは、見た目だけでは分からない。
だから、増幅器という語を肯定のまま使うと、完成品が増えたことを、能力が増えたことと取り違えやすい。否定のまま使うと、速度や射程が本当に広がる局面まで、使ってはいけない話に見える。どちらも、語の片側だけを固定した読みである。
個人の作業で到達範囲が広がることと、組織の成果が検証可能になることも、同じではない。一人の試作が速くなることと、障害時に答えられることは、別の層である。増幅器を組織のスローガンにすると、この差が消えやすい。
サイト名の「認知の足場」は、生成を止める枠ではない。低い層の負荷を外へ置き、人間が判断できる位置に立つための枠である。増幅器が入力を大きくするのに対し、足場は、大きくなったものをどこで引き受けるかを決める。
『AIによる認知スキャフォールディングとアイデア発散傾向の構造化』で扱ったのも、この分業である。発散や下書きは外へ出してよい。主張の強さと採否は、人間に残す。外へ出すこと自体が増幅であり、残す位置が足場である。
『地頭至上主義の系譜と認知資源の多元主義』の立場から言えば、頭の中だけで処理したか、機械で増やしたかは、正当性の基準にならない。増やした出力を検証し、統合し、その使用に責任を持てるかが残る。増幅したという事実は、成果の品質を保証しない。
『答え責任と外部化の線引き：AI協働における認知作業の委譲原理』で整理した境界は、ここでも使える。外部化できるのは、人間が根拠を示し、誤りを検出し、採否を決められる範囲に限る。その範囲の外で増幅すれば、増えるのは引き受けられない出力である。
先の「AIがコードを書く時代に、なぜ「お気に入りの言語」を持つのか」も、同じ問題の別面である。生成が速くなるほど、何を正しいとするかの基準点が要る。基準のない増幅は、候補を増やすだけである。
増幅器は、能力を伸ばす装置ではない。入力を大きくする装置である。能力が伸びて見えるのは、入力側に、すでに判断と検証があるときである。
よく使われる肯定用法は、その条件を省略していることが多い。省略しても、日常の試作では足りることがある。足りなくなるのは、流暢な出力を成果として通すときである。そのとき増えているのは、人間の射程ではなく、通った文とコードの量である。
何を増幅するかを決める、というのは、スローガンを選ぶことではない。依頼に制約を付ける、出力を読む、検証する、採否を残す、という作業を、増幅の前に置くことである。それが揃った増幅器は、足場の隣にある。揃わない増幅器は、誤りの増幅器である。
語を捨てる必要はない。語の片側だけを残すと、楽になった話と、壊れ方が速くなった話が、同じ文に見えてしまう。見るべきなのは、増幅そのものではなく、何が大きくなっているかである。
]]>