AI用語を、現場のことばに置き換える。

大量の文章で学習した言語モデル。文脈から次に来る語を予測する仕組みで、文章生成・要約・分類をこなす。

現場では: 「賢い検索」ではなく「もっともらしい文章を作る装置」。事実確認は人がやる前提で設計する。

モデルが文章を扱う単位。日本語はおおむね1文字が1トークン前後になることが多い。課金も速度もこの単位。

現場では: 料金試算は「1回の処理で入力何文字・出力何文字か」を数えるところから始めると外さない。

一度に読み込める入力の上限。1Mトークン級なら文庫本数冊分をまとめて渡せる。

現場では: 長ければ良いわけではない。無関係な資料まで入れると精度が落ちるので、渡す資料は選ぶ。

毎回同じ前置き（社内ルールや書式）を送るとき、その部分を再利用して割引を受ける仕組み。

現場では: 定型の前置きを固定し、変わる部分を後ろに置くだけで入力費用が大きく下がる。

モデルが事実でない内容をもっともらしく出力すること。自信のある口調で出るため気付きにくい。

現場では: 固有名詞・日付・金額・法令の4つは、AI出力をそのまま外に出さないルールにしておく。

社内文書を検索して、見つかった箇所だけをモデルに渡してから回答させる方式。

現場では: 「AIに社内知識を覚えさせる」より安く早い。まずは検索の精度に投資するほうが効く。

モデル自体を追加学習で調整すること。文体や出力形式を強く固定したいときに使う。

現場では: 小さな会社では大半のケースで不要。プロンプトとRAGで足りるかを先に検証する。

モデルが自分で道具（検索・ファイル操作・API）を選んで、複数手順の作業を進める形態。

現場では: 自動化の範囲を広げるほど失敗時の影響も広がる。最初は読み取り専用の権限から始める。

親のエージェントが、別文脈を持つ子エージェントに作業を切り出して任せる仕組み。

現場では: 調査など出力が長くなる作業を切り出すと、親側の文脈が汚れず判断がぶれにくい。

手順書をファイルとして置き、必要なときだけAIが読み込む仕組み。名前と説明だけを常時読み、本文は必要時に開く。

現場では: 「毎回同じ説明をしている」と気付いたら、それをSkillにする合図。

コーディングエージェント向けの共通指示ファイル。Linux Foundation 傘下の Agentic AI Foundation が管理する公開フォーマット。

現場では: READMEは人間向け、AGENTS.mdはAI向け。ビルド手順・命名規約・触ってはいけない場所を書く。

AIツールと外部システムをつなぐ共通プロトコル。1つのサーバーを複数のAIツールから同じ設定で使える。

現場では: 接続先が増えるほど権限管理が本体。最小権限と監査ログをセットで用意する。

モデルの重みが配布されており、自社環境で動かせるモデル。ライセンス条件はモデルごとに異なる。

現場では: 「外に出せないデータ」の処理を検討する際の選択肢。ただし運用コストは自社負担になる。

AIの出力を人が確認してから確定させる運用設計。

現場では: 確認する人・確認する項目・確認の記録場所を決めて初めて成立する。「あとで見る」は運用ではない。

AIの出力品質を、あらかじめ用意した事例で継続的に測ること。

現場では: 10件でいいので「これができていれば合格」の実例を作る。モデル変更時の判断が一瞬で終わる。

読み込ませた外部データの中に指示文を混ぜ、AIの動作を乗っ取る攻撃。

現場では: Webページやメール本文をAIに読ませる処理では、その内容を「指示」ではなく「データ」として扱う設計にする。