AIが知っているのは、世の中の標準です。あなたが欲しいのは、自社の答えです。その差分は、AIの性能ではなく、AIに渡す情報で埋めるしかありません。

高度なモデルを使っているのに、欲しい答えが返ってこない。この相談をよく受けますが、原因はほぼこの差分にあります。そして、AIに任せるときに必要な情報量は、新人にその仕事を任せるときに必要な情報量と、ほぼ同じです。

前回の記事で、AIの確率的な挙動を業務のどこに置くかという話を書きました。今回はその対になる話で、AIが参照する知識をどこに置くか、という話です。着地は同じです。本体はAIではなく、AIに渡す情報のほうにあります。

AIは、渡さなければ標準的な答えしか返せない

まず前提として、AIは世の中のテキストから学んだ「もっともらしい答え」を返す仕組みです。固有の情報を渡さなければ、一般的で標準的な知識をもとに答えるしかない。あなたが欲しい答えを知っているわけではないので、欲しい答えがあるなら、それをあらかじめ伝えておく必要があります。

この先どんなにAIが賢くなっても、ここは変わりません。賢さが上げるのは標準的な答えの質であって、あなたが何を欲しいかは、性能では埋まらないからです。

AIに渡すことと、人に渡すことは同じ作業

たとえば、誰かに何かを伝える文章を書くとします。文体や体裁、誤字脱字の話を除けば、書き手に明確に伝えたいことがあるなら、AIが持ってくるものはありません。AI自体には伝えたいことがないので、内容は人が渡すしかない。そして、AIに内容を渡す作業と、それを他の人に渡す作業は、同じ作業です。

だから、AIを使えばすべてが楽になる、というわけではありません。楽になるのは、伝えたいことがすでに言語化されている場合です。

逆に、内容を渡さずにAIに任せると、伝えるべき内容そのものが変わってしまいます。「AIの使い方を社内向けにまとめて」と頼めば、それらしい文章は出てきます。でもそれは標準的な内容であって、自分が経験して得たノウハウではない。読んだ人は、標準的なことを知るだけです。

積算業務で言えば、「積算して」と伝えるだけではだめで、新人が積算をできるようになる程度の情報は当然必要です。単価表、拾い方のルール、例外の扱い、過去の案件でどう判断したか。これは新人に教えるときに渡す情報と、まったく同じものです。

言い換えると、新人に任せられる程度に言語化できていない仕事は、AIにも任せられません。「AIに何を渡せばいいか分からない」という状態は、たいてい「その仕事がまだ言語化されていない」という状態です。

渡す情報は三種類ある

では、その情報をどう管理するか。「どこに誰が保存するのか、フォーマットは何か、人が更新するのかAIが更新するのか、どうやってAIに渡すのか」を考えていくと、情報は三種類に分かれます。

この分類が決まると、保存場所も決まります。固定のルールは誰もが同じものを参照すべきなので、一か所に置いて全員が同じものを渡す。更新される情報はDBや文書に置いて、検索できるようにする。使い捨ての情報は、チャットに書けばいい。

前回の記事で「中央化されるのはAIではなく、AIが参照するデータとルール」と書きましたが、その中身がこの表の上二行です。

ベースは渡し、残りは検索させる

なぜ三種類に分ける必要があるかというと、AIに一度に渡せる情報には限りがあるからです。チャットのようなUIでは、一つの会話で保持できる情報量が有限で、膨大な前提情報を全部載せることはできません。

なので設計としては、ベースとなる知識（固定のルール）は最初に渡し、必要な情報（更新される情報）は検索させる、という形になります。全部を渡そうとすると入りきらないし、全部を検索させると毎回ルールを見失う。

この制約はモデルの進化で緩む可能性がありますが、原則は変わりません。汎用知識と自社の知識は別物で、後者はどこかに置いて渡さなければ、AIにとっては存在しないのと同じです。

AIが「知っている」ように見えることの罠

勘違いしやすいのは、AIがネット上のテキストを学んでいるので、何でも知っているように見えることです。積算の一般的な手順も、業界の用語も、それらしく答えます。

でも、それは標準的な知識であって、あなたの会社の単価表でも、あなたの会社の判断基準でもありません。AIが持っている知識を使おうとすると、たいてい失敗するのはこのためです。一般論としては合っているが、自社の答えとしては違う、という結果になります。

冒頭に書いた通り、標準と自社の答えの差分は、渡すしかありません。

結局、言語化と置き場所の話に戻る

まとめると、こうなります。

AIは渡さなければ標準的な答えしか返せず、欲しい答えは渡す情報で決まる。渡す情報は、人に渡すときと同じものが必要で、それが言語化されていない仕事はAIにも任せられない。渡す情報は固定のルール、更新される情報、使い捨ての情報の三つに分かれ、前二つは置き場所を決めて管理する必要がある。

だから、AIを使いこなすために必要なのは、AIの操作方法ではなく、自分の仕事を新人に教えられる程度に言語化することと、それを置く場所を用意することです。前回の記事のデータ整備と、言っていることは同じです。AIに渡す準備ができている会社は、AIが賢くなるたびに、そのまま恩恵を受けられます。

AIに任せられる仕事は、新人に任せられる仕事です。

AI導入の相談を受けると、たいてい「全部AIに任せられないか」という話から始まります。私の考えは逆で、AIは定型業務の実行経路には極力置かないほうがいい。置く場所は、人が触る対話的なUIと、業務の仕組みを作る開発の場面です。

先に、この記事の主張を一文にしておきます。

AI導入で考えるべきなのは「どの仕事をAIにやらせるか」ではなく、「確率的な処理をどこまで許し、どこから先を決定論的な仕組みに固定するか」である。

そのうえでの結論は次の通りです。

• 確率的な処理を実行時に持ち込まない：計算も、入力の取り込みも、テスト可能で再現可能な仕組みでやる
• AIの不安定さは開発時に一度だけ引き受ける：AIにパーサーやスクリプトを書かせ、レビューしてコードに固定する
• 業務システムへの組み込みは待つ：各社の成功事例は準備工数が隠れており、まだ見極めの段階
• 個人の道具としての配布は今すぐ：全員にアカウントを配り、最低限のルールとセットで試してもらう
• データ整備は今すぐ：AIがどう転んでも必要な投資で、後回しにする理由がない

避けたいのはAIではなく、確率的な挙動の実行時への持ち込み

最初に定義しておきます。私が避けたいのはAIそのものではなく、AIの確率的な挙動を、監査対象となる業務処理の実行時に持ち込むことです。本番で動く処理は、テスト可能で、再現可能で、失敗を検知できるものであるべきだ、という原則です。

まず計算について。アルゴリズムや数式で明確に答えが出るものをAIに計算させると、はっきりしたデメリットがあります。再現性がなく、監査ができず、桁を間違えることもある。原価計算や積算そのものをAIにやらせるべきではありません。ここは多くの人が同意すると思います。

次に入力の取り込みについて。現場からは「散らばったPDFやメール、Excelから数字を拾って表に揃える作業をAIにやらせたい」という要望がよく出ます。AIは非構造データの構造化が得意なので、一見これはAI向きの仕事に見えます。しかし、私はここにもAIを置くべきではないと考えています。理由は二つあります。

一つ目は、ごちゃごちゃは正しくない状態だということです。整理する余地がある業務は整理すべきであって、ごちゃごちゃのままAIに吸収させると、そのごちゃごちゃが仕様になり、業務がロックインします。「ムダを自動化するな」という昔からの原則と同じですが、AIの場合はさらに厄介で、中身がブラックボックスなので、後から「なぜこういう整理になっているのか」を誰も説明できず、剥がせなくなります。

二つ目は、業務の入力を分解すると、AIでしか処理できないものがほとんどないことです。

• 繰り返し来る定型：量が多いので自動化の価値は高いが、形式が固定なので、入力形式・変換ルール・エラー条件を明示できる仕組みに落とせる。内部でOCRや機械学習を使っているかどうかは問題ではなく、出力仕様と検証方法が固定されていることが重要
• たまに来る非定型：量が少ないので人がやればいい。しかも「たまに」ということは検証もテストも積み上がっていないので、AIが一番間違えやすく、一番間違いに気づきにくい領域。AIは危険
• 大量に来る非定型：ここだけがAIの出番になりうる。ただし、その前に「本当に非定型である必要があるか」を疑うべき。フォーム化や標準化で減らせる非定型をAIで吸収するのは、業務改善を先送りしているだけ

それでも残る非定型はあります。取引先からの自由記述メール、契約書、図面、問い合わせなどです。ただ、これらをよく見ると、処理経路で確定させるものではなく、人が判断する材料をAIに出させる、つまり後述する「人が触る層」で扱うものがほとんどです。入口にAIを置きたくなる状況は、AIで解くべき問題ではなく、業務を直すか、扱う層を間違えているかのどちらかです。

不安定さは開発時に一度だけ引き受ける

では、AIの使い道はどこにあるのか。実行時ではなく、開発時です。

取引先の様式を見せてパーサーを書かせる。OCRの後処理ルールを作らせる。テストデータを作らせる。本番で動くのは決定論的なコードで、AIはそれを書く手伝いをするだけ、という形です。

これの何がいいかというと、AIの不安定さを引き受けるタイミングが変わります。AIの不確実性をなくすことはできない。できるのは、不確実性を引き受ける場所を選ぶことだけです。

実行時にAIを置くと、毎回の処理ごとに不安定さが乗り、毎回の出力を誰かが確認しなければならない。開発時に置くと、不安定さは一度きりで、その一度の出力であるコードを人がレビューしてテストを通せば、あとは決定論的に何万回でも同じ結果が返ります。確認のコストが「毎回」から「一回」になります。

しかも確認の対象がコードなので、確認しやすい。AIが出した数字が正しいかは元の伝票と突き合わせないと分かりませんが、AIが書いたパーサーが正しいかは、テストデータを通せば分かるし、差分も追えるし、直したければ人が直せます。相手の様式が変わったら、またAIに書き直させて、またレビューする。不安定さを一度コードに固定して、その固定物だけを管理する。

言い換えると、AIは「答えを出す係」ではなく「答えを出す仕組みを作る手伝いをする係」です。この原則で整理すると、業務の構成は次の5層になります。

「パーサーやスクリプトを書くのはエンジニアの仕事では」と思われるかもしれません。今はそうですが、この前提はすぐに消えると思っています。「この伝票からこの項目を取り出して、この形式で出したい。それを毎回同じように呼べるようにしてほしい」とAIに頼めば、コードを読めない人でも再利用できる道具が作れる。コードを書く能力そのものの重要性は下がっていくと思います。その代わり、「何を入力し、何を出力し、どんなケースで失敗とみなすか」を定義して検証する能力が重要になります。プログラミング能力から、仕様化と検証の能力へ重心が移る、ということです。

つまり前提がゼロになるのではなく、別のものに置き換わります。一つは今述べた検証です。作った道具が正しいかは、テストデータを通して自分の目で確かめる必要があります。これはコードが読めなくてもできるし、むしろ業務を知っている人のほうが向いています。もう一つは置き場所です。各自がAIに道具を作らせ始めると、Excelマクロが各自のPCに乱立したのと同じことが起きます。作った道具は共有の場所に置き、みんなが同じものを呼ぶ形にしないといけません。この点は後述する「中央化されるのはAIではなく、AIが参照するデータとルール」という話に、道具も含まれる、ということです。

「AI導入」には二種類ある

ここから先は「今、何をするか」の話です。その前に、言葉を分けておきます。

「AI導入」という言葉には二つあります。一つは、業務フローそのものにAIを組み込む導入。もう一つは、Excelや検索エンジンのように、社員個人の道具として配る導入です。前者はまだ慎重でよく、後者は今始めてよい、というのが私の考えです。以下、それぞれについて書きます。

個人の道具としてのAIは、中央に置くものか、パーソナルなものか

個人の道具としてのAIがどんな形になるのか、実はまだ答えが出ていません。ERPのように中央に設置してみんなで使うものになるのか、ExcelやPC本体のようにパーソナルな道具になるのか、はっきりしていないからです。

いまのところ、パーソナルな道具になる可能性が高いと見ています。ただ、ここでExcelの歴史を思い出す必要があります。Excelも最初はパーソナルな道具として広がり、各自のシートが乱立してマスタが壊れ、結局DBやERPに戻す動きが起きました。

AIもおそらく同じ経路をたどります。入口はパーソナルで、しばらくすると「みんなが同じ社内規程や単価表を参照したい」「出力を揃えたい」となる。そのとき中央化されるのはAIそのものではなく、AIが参照するデータとルールの部分だと思います。

現状、ERP的な中央集権のやり方で成功しているのが、膨大なナレッジの検索やお問い合わせ対応など、かなり限定的な領域に留まっているのも、それらが「共有データへの参照」だからです。この見立てと整合しています。

「配って自由に使わせる」戦略と、セットにすべき3点

こうした事情から、現時点では、使い方を最初から細かく決めるより、とりあえず広くアカウントを付与して自由に試してもらう、という戦略もよく見られます。実態としては、ほとんどの人は使わないけれど、一部の人がめちゃくちゃ使いこなす、という分布になります。

ただ、配って放置すると3つのことが起きます。

1. 機密データが外に流れる
2. 使いこなしている人のやり方が組織に残らない
3. 使わない人が使わないまま

なので、最低限この3点はセットにしたほうがいいです。

1. 入力してよいデータの線引き：顧客名・単価・図面など、外部サービスに入れてよい範囲を明文化する
2. 月1回程度の事例共有の場：使いこなしている人のプロンプトや手順を見せてもらう
3. 社内データを安全に参照できる仕組みの検討：権限付きの社内検索や、社内文書を参照して回答する仕組み（いわゆるRAG）など

業務システムへの組み込みは「見極めるタイミング」

一方、業務フローへの組み込みについては、いまは各社が試している段階で、積算をAIにやらせたり、伝票発行をAIにやらせたり、いろいろな取り組みがあります。ただ過大広告の部分もあり、「効果が出た」と謳っている裏で、膨大な工数をかけて準備していたりします。全面導入するタイミングではなく、見極めるタイミングだと思います。

とはいえ、これは「やるかやらないか」の様子見ではありません。AIが業務で使われる道具になっていくこと自体は、私は疑っていません。もう少しベストプラクティスが集まってから挑戦するか、あるいは前述のとおり全員にアカウントを配って各自に試してもらうか、そのどちらか（または両方）がいいと思います。

待っていても解決しないのがデータ整備

その上で、待っていても解決しないものが一つあります。データ整備です。

成功事例の裏にある「膨大な準備工数」の中身は、要するにマスタ整備、単価表の一元化、帳票のデジタル化です。言い換えれば、社内のごちゃごちゃをなくす作業です。これはAIがどう転んでも必要な投資なので、ここだけは今から着手して損はありません。

逆に、これをやらないままAIを入れると、ごちゃごちゃごとロックインします。そしてこれが済んでいれば、ベストプラクティスが出た瞬間に乗れる状態になります。

この構造はAI自身が向かっている方向でもある

最後に、この記事の主張が「AIに慎重な人の守りの話」ではないことを書いておきます。

AIが高度になるほど、AI自身もすべてを言語モデルで処理するのではなく、コードを書き、検索し、計算機やAPIを呼び、決定論的な道具に処理を委譲する方向へ進んでいます。つまり「AIに答えを出させる」のではなく「AIに答えを出す仕組みを作らせる」という構造は、AIの進化と逆行するどころか、その延長線上にあります。

そうなったとき、人の役割は処理そのものではなく、AIが固定しきれていない部分、つまりテストが通っていない、前提が曖昧、根拠が説明できない、といった不完全な部分を見つけて整理することに変わります。

だから人間側が今やるべきことも、AIに仕事を渡すことではなく、AIが使える道具・データ・ルールを整えることです。

AI導入は待てる。データ整備は待てない。

ポジションがあがると効果の大きい仕事をする必要がある前提として。1)難易度も高くやりがいもあるけど、1人が1回だけ使うシステムを作る仕事。2)判断するだけの簡単な仕事だけど、数十人が永遠に業務が変化する。みたいな感じで、整理することが大切。どちらのほうが大切という意味ではないけどそういう見方があることを知っておく。
重要なのは、小さい仕事を解決するときに、できるだけ、良い影響力を大きく与えるような解決策を選ぶ。例えば2人のトラブルがあったら、間に入って親身に対応が1でトラブルが起きないようにルールを変えるのが2ということ。

仕事で何かを判断するとき絶対的な正解はない。一般的に正解と言われることだって、自社にとってただしとは限らない。ではその判断基準は。例えば人でもブランドにおかねをかける人。食事にお金をかける人、ひとそれぞれ。会社も同じでカラーがあり、それを決めるのは、経営者であったり、それを決めることが仕事の人。自分はそのカラーにあった判断をすることが大切。正確にいうと、一番末端で決まったことを作業するだけと一番上で決める人がいるとしたらその間はグラデーションなので、それぞれ作業と決めることのバランスがある。

多様性と集中を定期的に鼓動のように繰り返す
進化など参考にすると多様性が重要という意見もある。同じ条件で戦っている以上、資源を集中させないと競争に勝てないという意見もある。
自然にその波は訪れないので、自発的に起こす。広げる時期、集中する時期。

技術革新と業務改善は別の戦い。
業務改善を突き詰めても、ある日技術革新で勝負の土俵が変わることがある。では業務改善が無駄かというと、日常では業務改善の争いになる。

無限の試行の前提での絶対的な成功法則や理論はないけど、ある期間を取り出してみると、
有効なものはある。投資などでもそう。重要なのは、かならず時間の範囲を想定して考える。

プロジェクトを進めるときは共通認識を作るところから始める。
簡単な箇条書きや数字でいい。特にシステム導入なので、各自の見える世界が違うとき、
やんわりとしたお互いの想像同士で空っぽの空間で理解するような状態を作らない。具体的なものを見て進める。

常に安くて早いが基本。いいもの使っているから高いとか、ブランドイメージで勝負するとか、それ自体戦略として存在するし需要もある。でも安易に選ぶと、その戦略は努力でカバーできない要素が多くなるし、商売の基本ではないことを覚えておく。

徹底的に最適解を探すと最後のつめの部分で大きなコストがかかる。80%程度と考えると速度を出せる。全ての仕事が80でいいわけではない。時と場合。

目的に対してどうでもいいことは早く決める。多くの人は逆にそういう部分にこだわりがでているので、折れても良い部分なら折れること。

新しいことに挑戦や負荷がかかったときに成長できる。会社の機器の入れ替えとか。自宅ラボの構築とか。そういうタイミングを積極的に作ること。

ある時期々々で、テーマを作る。これはビジネスでは当然ではあるけど、年度目標とか。
お金になりがちだけど、IT部門でいえば、作業のストレスがない環境構築とか。

なんでもかんでも費用対効果で語る必要はない。語れない物も多いのに、無理やりコスト削減を強調するのはおかしい。意思決定としてはカラーという前提があるので、それをどう解釈するか。また、作ったテーマに沿った提案でいい。

プロジェクトは常に共有しておく。根回し、巻き込み力みたいな表現あるけど、決裁する側、利用する側など関連する人たちには共有しておく。

自分の時間単価を計算して動く。

・インストール後のおすすめモデルはスキップ

左サイドメニュー一番下から
Qwen3.6-35B-A3B
を検索し、チェックが付いている
MLXの4BIT(20.43 GB)
をそのままダウンロード。

・ビット

実効ビット=ファイルサイズ(GB)*8/パラメータ数(B)
変数が二つあるとモデル比較できないため1つのパラメータにしている。
また、このパラメータが品質の目安になるからというのもある。
3ビット以下は実用性がなく4ビットが標準になっている。
パラメータ数が多いほど低ビットにたえる。同じ容量なら14B・8bitより35B・4bit。

・量子化する

開発元はbf16で公開する(Google、Alibaba、NVIDIAなど)
第三者が低ビットにすること＝量子化＝ｑ
音楽と一緒で今の配布の基準が16ビットになっているだけ。

・q_4_K_M

q=量子化している印(nvfp4などもある)
4=何ビットか。
K=K-quant方式。第二世代の方式。
M=S/M/LでMが標準、Sは軽量、Lはほとんどない。

●ESET PROTECTソリューションユーザーズサイト

・日本代理店のキヤノンのサイト
https://canon-its.jp/product/eset/users/

●ESET

・共通認証基盤
https://identity.eset.com

・ビジネスアカウント
https://eba.eset.com

・クラウド版コンソール(セキュリティ管理ツール)
https://protect.eset.com/era

キヤノンでライセンス情報を取得しebaで登録すると、自動でeraに表示されるので、端末をアクティベーションという流れ。

※ライセンスを登録
https://eset-support.canon-its.jp/faq/show/17938?site_domain=business

※アクティベーション
https://eset-support.canon-its.jp/faq/show/13245?site_domain=business

●セキュリティ管理ツール

コンピュータ一覧から削除する場合、端末が破損などしている場合、
データベースから削除だけでOK。
端末がまだ使われている場合、
コンピュータの管理を停止→削除と実行する。

●EBA/ERA

ERAから保存したクライアントをインストールすると、通常EBA/ERAに登録される。個人版クライアントなどでアクティベートしたりするとEBAにだけ存在する場合がある。ライセンスの有効期限が切れたりするとERAにだけ存在する場合がある。

OpenBSDダウンロード

cd ~/Downloads
curl -O https://cdn.openbsd.org/pub/OpenBSD/7.9/arm64/install79.iso
curl -O https://cdn.openbsd.org/pub/OpenBSD/7.9/arm64/SHA256
shasum -a 256 install79.iso
grep install79.iso SHA256 # 一致を目視確認

UTMダウロード

https://mac.getutm.app/
からダウンロード

仮想マシン作成

新規仮想マシンを作成
仮想化
その他
メモリ:2048
コア:2
CD/DVD:install79.iso
UEFI:チェック
ストレージ:20GiB
共有ディレクトリ:スキップ
名前:OpenBSD 7.9

OpenBSDセットアップ

(I)nstall
Terminal Type: vt220
System hostname: bsd
Network interface to configure: vio0
IPv4 address for vio0 (or ‘autocnf’ or ‘none’): autoconf
IPv6 address for vio0 (or ‘autoconf’ or ‘none’): none
Network interface to configure (name, lladdr, ‘?’, or ‘done’): done
Password for root account: 1234
Start sshd(8) by default: yes
Setup a user: testuser
Full name for user testuser: testuser
Password for user testuser: 1234
Allow root ssh login: no
What timezone are you in: Asia/Tokyo
Which disk is the root disk: sd0
Encrypt the root disk with a (p)assphrase or (k)eydisk: no
Use (W)hole disk or (E)dit the MBR: whole
Use (A)uto layout, (E)dit auto layout, or create (C)ustome layout: auto
Location of sets (cd0 disk http nfs or ‘done’): cd0
Pathname to the sets: 7.9/arm64
Set name(s) (or ‘abort’ or ‘done’): -x* -game79.tgz
※xbase79 xfont79 xserv79 xshare79 の [X] が外れたのを確認
Set name(s) (or ‘abort’ or ‘done’): done
Directory does not contain SHA256.sig Continue without verification: yes
※インストール
Location of sets (cd0 disk http nfs or ‘done’): done
Exit to (S)hell, (H)alt or (R)eboot: reboot
※rebootの前にUTM側でISOを取り出す

起動後

・ターミナルSSHログイン

ipアドレスを確認
ifconfig vio0

SSHで接続
ssh testuser@192.168.64.2

・doas

su –
echo “permit persist keepenv :wheel” > /etc/doas.conf
exit

・syspatch

doas syspatch
※自動でアップデートされる
doas reboot

・syspatchコマンド

利用可能なパッチを全部取得・適用
doas syspatch

適用済みパッチ
syspatch -l

何が来ているか確認だけ(適用しない)
doas syspatch -c

適用済みパッチの一覧
syspatch -l

直近のパッチを取り消す
doas syspatch -r

不要サービス停止

・起動中のサービス
doas rcctl ls started

cron
dhcpleased
ntpd
pflogd
resolvd
slaacd
smtpd
sndiod
sshd
syslogd

・停止するサービス

オーディオ
doas rcctl stop sndiod && doas rcctl disable sndiod

SLAACクライアント(IPv6)
doas rcctl stop slaacd && doas rcctl disable slaacd

DHCPクライアント停止

doas rcctl stop dhcpleased && doas rcctl disable dhcpleased

cat /etc/hostname.*
が
inet autoconf
の場合、dhcpleasedをとめては駄目。
もし先に止めた場合、
doas rcctl enable dhcpleased && doas rcctl start dhcpleased
にて有効化できる。

resolvd停止

/etc/resolv.confを書き換える係
※dhcpleasedが有効ならこちらも有効にする。
doas rcctl stop resolvd && doas rcctl disable resolvd
doas rcctl enable resolvd && doas rcctl start resolvd

cat /etc/resolv.conf
nameserver 192.168.64.1 # resolvd: vio0

固定IPにする場合

/etc/hostname.vio : インターフェスのアドレス
/etc/mygate: デフォルトゲートウェイ
/etc/resolv.conf: 名前解決の問い合わせ、順序
※resolv.confだけデーモンが書き換える

/etc/hostname.vio0
/etc/hostname.vio1
にIPアドレスを書く
inet 192.168.64.2 255.255.255.0
のようなフォーマット。inet autoconfは削除する。

サービス調べ方

・起動時に上がるサービス(startedはすでに起動しているサービス)
rcctl ls on

・起動に失敗しているサービス
rcctl ls failed

・状態確認
rcctl check <name>

・起動失敗の理由
tail /var/log/daemon

・全部(rc.d にあるスクリプト全て)
rcctl ls all

・無効になっているもの
rcctl ls off

・今動いていないもの
rcctl ls stopped

・プロセス一覧(rcctlはサービス単位)
ps auxw

・待ち受けているポート
netstat -an -f inet

ネットワーク設定

UTM	Parallels	VMware	VirtualBox
Shared	共有ネットワーク	NAT	NAT
Host Only	ホストオンリー	Host-only	ホストオンリー
Bridged	ブリッジ	ブリッジ	ブリッジ

Parallelsの共有ネットワークは10.211.55.0/24
ホストオンリーは10.37.129.0/24

HostOnlyはホストOSとゲストOSをL2スイッチで繋いだイメージ。ホストOSがDHCPとして振る舞うがNAT・ルーティング機能はない。複数のゲストOSを立ち上げた場合そのL2スイッチに複数つながっているイメージ。

SharedはHostOnlyと同じ配線でホストOSがNAT・ルーティングまでするルータとして振る舞うイメージ。

Bridgedは論理的に独立したNICになり、MACアドレスも別になる。(BridgedではWiFiは機能しない。WiFiは1つのアソシエーションで1つのMACアドレスのため)MacがホストOSの場合、Shared、HostOnlyでもbridgexxxというインターフェースが作成されるが、Bridgedで動作しているわけではないので注意。

ルーター設定

・UTMでNIC追加

起動していたらVMをシャットダウンする。

既存VM>右クリック>編集
サイドメニュー>デバイス>新規>ネットワーク
ネットワークモード:ホストのみ>保存

ifconfig
vio1が表示されていればOK

・DHCPでvio1を有効化

doas ifconfig vio1 up
doas dhcpleasectl vio1
ifconfig vio1
>192.168.128.2

・vio1静的アドレスファイルを作成

doas vi /etc/hostname.vio1
inet 192.168.128.254 255.255.255.0

doas chmod 640 /etc/hostname.vio1
doas chown root:wheel /etc/hostname.vio1

・vio1再起動

doas sh /etc/netstart vio1
ifconfig vio1

・vio1のDHCPを外す

doas ifconfig vio1 -autoconf
(doas ifconfig vio1 delete)
doas sh /etc/netstart vio1
ifconfig vio1

※ifconfigにAUTOCONF4があるとDHCP

・転送を有効化

doas sysctl net.inet.ip.forwarding=1

・恒久化

doas vi /etc/sysctl.conf
net.inet.ip.forwarding=1
を追加する。

・確認

sysctl net.inet.ip.forwarding

経路
netstat -rn -f inet

・pf.conf

doas cp /etc/pf.conf /etc/pf.conf.ok
doas vi /etc/pf.conf

・検証
doas pfctl -nf /etc/pf.conf

・適用
doas pfctl -f /etc/pf.conf

・動いているルールを表示
doas pfctl -sr

マック内UTMインラインルーテッド
※検証→結果失敗

・転送
doas sysctl net.inet.ip.forwarding=1

・転送永続化
/etc/sysctl.conf
net.inet.ip.forwarding=1

・マックでWireGuardのアプリをインストール

左下+
設定が空のトンネルを追加
名前をつける(UTM-BSDなど)
公開鍵を控える
保存

・インターフェース作成

秘密鍵作成
openssl rand -base64 32

doas touch /etc/hostname.wg0
doas chmod 600 /etc/hostname.wg0
doas vi /etc/hostname.wg0

ファイルに以下書き込み
wgkey <作成した秘密鍵>
wgport 51820
wgpeer <macの公開鍵> wgaip 10.254.0.2/32
inet 10.254.0.1 255.255.255.0
mtu 1420
up

インターフェース立ち上げ
doas sh /etc/netstart wg0

doas ifconfig wg0
wgpubkey(公開鍵)を控える

・MacのWireGuardアプリ設定

作成したトンネルの編集から以下書き込む

[Interface]
PrivateKey = <Macの秘密鍵>
Address = 10.254.0.2/32

[Peer]
PublicKey = <VMの公開鍵>
Endpoint = 192.168.64.2:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

・pfにNAT追加

doas vi /etc/pf.conf
を編集

ext_if = “vio0”
wg_net = “10.254.0.0/24”
set skip on lo
match out on $ext_if inet from $wg_net to any nat-to ($ext_if:0)
block return
pass

doas pfctl -nf /etc/pf.conf # 構文チェック。何も出なければOK
doas pfctl -f /etc/pf.conf
doas pfctl -sr

ルータ動作

転送の整理

ポートに届いたパケットは、
・宛先のL3(IP)
・宛先のL2(MAC)
・送信元のL3(IP)
・送信元のL2(MAC)
を持っており、ポートが受け取るのは、宛先MACが自分、ブロードキャスト、加入マルチキャストのいずれか。
宛先IPが自分でなく、かつ転送機能が有効なら、経路表でマッチした行の出口ポートから出し、宛先MACはその行のGatewayから決まる。
送信元、宛先MACはホップごとに書き換わる。
IPはNATを通るときに書き換わり、(送信元NATなら送信元、宛先NATなら宛先)、NATが無ければ最後まで変わらない。
自分以外の宛先に転送する度にTTLを一減らす。

WebGUI設定

初期設定の場合、次のパラグラフのコンフィグ作成、流し込んでからWebで以下を設定する。

ユーザー作成

WebGUI>保守>コマンドの実行>
login user skuser xxx

SSH有効化

WebGUI>アクセス管理>各種サーバーの設定
SSH有効化

※WebGUIでSSHを有効にするとKeyは自動で生成される。

※WebGUIコマンドからは生成できないので以下はコマンドでは実行しない。
sshd service on
sshd host key generate(手動で一度だけのコマンド)

SSH接続

ssh xxx@192.168.xxx.xxx

※SSHクライアントが新しい場合
ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 -oHostKeyAlgorithms=+ssh-rsa xxx@192.168.xxx.xxx

管理権限昇格

administrator
>空白

パスワード設定

administrator password
>xxx

login password
>xxx

ログアウトタイマー

user attribute skuser login-timer=7200

名前なしユーザーをシリアル限定

user attribute connection=serial

コンフィグ記入

表示設定

console character en.ascii
console lines infinity

アクセス範囲指定

httpd host 192.168.5.0-192.168.5.255 192.168.113.0-192.168.113.255
sshd host 192.168.5.0-192.168.5.255 192.168.113.0-192.168.113.255

PPTP/L2TP/TELNET

デフォルト
※httpd / 有効 / lan
※telnetd / 有効 / any
※sshd/pptp/l2tp / 無効

pptp service off
l2tp service off
telnetd service off

Defaultgateway

ip route default gateway <>
pp 1
dhcp lan2
xxx.xxx.xxx.xxx
tunnel 1

ローカルブレイクアウト

ip route default gateway tunnel 1
ip route <他拠点グローバルアドレス> gateway <ローカルWANアドレス>

他拠点のアクセスしたいセグメント
ip route 192.168.xxx.0/24 gateway tunnel 1

ローカルブレイクアウトしたいアドレス
ip route xxx.xxx.xxx.xxx gateway <ローカルWANアドレス>

LAN1 Address

ip lan1 address <>
xxx.xxx.xxx.xxx/24

LAN2 Address

ip lan2 address <>
dhcp
xxx.xxx.xxx.xxx/xx
pp select 1

DNS

dns server <>
xxx.xxx.xxx.xxx(NURO Bizなど指定のアドレス)
xxx.xxx.xxx.xxx(拠点間VPNで他拠点抜けの場合、他拠点のローカルアドレス)
pp 1

※プライベートアドレスの問い合わせを外部に漏らさない
dns private address spoof on

dns service <>
recursive
off

自身がクライアントからのDNS問い合わせを受け付けるかどうか。
※recursiveが初期値

dns server xxx.xxx.xxx.xxx
DNSの問い合わせ先

dns serverの設定で、拠点間VPNをFQDNやネットボランチDNS名で書いている場合、トンネルを張るには名前解決が要る、名前解決にはDNSが要る、DNSにはトンネルが要るデッドロックになる。

dns host 192.168.0.0-192.168.255.255
DNS問い合わせの受け付ける範囲

NAT

ip lan2 nat descriptor 1000
nat descriptor type 1000 masquerade
nat descriptor address outer 1000 <>
ipcp / PPPoE
primary / DHCP
xxx.xxx.xxx.xxx / 静的IP

※これはデフォなので不要
nat descriptor address inner 1 auto

・NAT配下のIPsec終端

nat descriptor masquerade static 1 1 xxx.xxx.xxx.xxx udp 500
nat descriptor masquerade static 1 2 xxx.xxx.xxx.xxx esp
nat descriptor masquerade static 1 3 xxx.xxx.xxx.xxx udp 4500

DHCP

dhcp service server
dhcp scope 1 192.168.xxx.2-192.168.xxx.254/24
dhcp server rfc2131 compliant except remain-silent

PP

※ 起動
pp select 1 ~ pp enable 1

※ 基本
pppoe use lan2
pp auth accept pap chap
pp auth myname (ID) (PASS)
ip pp nat descriptor 1000

※ 常時接続
pp always-on on
pppoe auto disconnect off

※ mtu / mru / mss
ppp lcp mru on 1454
ip pp mtu 1454
ip pp tcp mss limit auto

※ IPCPで貰うペア
ppp ipcp ipaddress on
ppp ipcp msext on

※ 圧縮なし
ppp ccp type none

拠点間VPN

ip route xxx.xxx.xxx.xxx/24 gateway tunnel 1
ipsec auto refresh on

※ 起動
tunnel select 1 ~ tunnel enable 1

※ トンネルIPsec紐づけ
ipsec tunnel 1

※ 暗号方式
ipsec sa policy 1 1 esp 3des-cbc sha-hmac

※ 認証手段
ipsec ike pre-shared-key 1 text xxx

※ 相手
ipsec ike remote address 1 xxx.xxx.xxx.xxx

<条件付必須>

※ 両側グローバルIPなら不要
ipsec ike nat-traversal 1 on

ip tunnel tcp mss limit auto
ipsec ike keepalive use 1 on heartbeat 10 6
ipsec ike local address 1 xxx.xxx.xxx.xxx

<以下なくてもOK>

※ メモ
description tunnel test

※ ログ量
ipsec ike keepalive log 1 off

その他

MTU/MRU/MSS

MTU
IP層で送信できるIPパケット全体サイズ
1454

MRU
PPP層で自分が受信できる最大サイズ
1454

MSS
TCP層でデータ部分の最大サイズ
MTU-40

リモート接続環境で設定更新

・現状の設定がちゃんとフラッシュかどうか

show environment
を実行すると、今読まれているもの、
Config. file: config0
再起動時に読まれるもの
Default config. file: config0
が分かるので、一応確認しておく。

・コンフィグ失敗バックアップ

以下は10分後に保存済みを読み込んで立ち上がる。
schedule at 9 +600 * restart

一度
show config
でスケジュール入ったか確認しておく。

設定がうまくいった場合は、
no schedule at 9
でスケジュール削除し、
save
で保存する。
これをやらないと起動後定期的に再起動してしまう。

※RTX810とか古い機種
schedule at 9 7/31 23:10 * restart
no schedule at 9

 

① PPPoE設定(pp select / pppoe use)
② DHCPクライアント(ip lan2 address dhcp)
③ 静的IP(ip lan2 address 固定IP)
④ MAP-Eトンネル(tunnel encapsulation map-e)
⑤ IPIPトンネル(tunnel encapsulation ipip)

PPPoE、IPoEは接続方式の違いだが、ほとんどIPoE=over6となっているので、ここではIPv4=PPPoE、over6=IPoEとする。

over6は物理回線で認証する。over6は基本的にIPv6シングルスタックと同じで、その上にIPv4にも繋がる仕組みが乗っている感じ。相手がIPv6対応サイトなら最後までIPv6で届き、相手がIPv4サイトならルーターISP網出口の間だけカプセルでつつむだけ。PPPoEの場合は、全区間IPv4になる。

以前はPPPoEの契約でオプションとしてover6がほとんどだった。当時はIPv4はPPPoEで、IPv6サイトはIPoEという状態。(IPv6オプション)
現在のover6はPPPoEを使わずIPoEの上にIPv4を通すのも増えてきた。(DS-Lite/MAP-E)

・PPPoE設定
一般ISP（動的IP／固定IP）

・DHCPクライアント

・静的IP

・MAP-Eトンネル
v6プラス、OCNバーチャルコネクト（共有・動的IP）

・IPIPトンネル
transix（DS-Lite・共有）

・IPIPトンネル
v6プラス固定IP（専用固定）

 

・PBR/インラインルーテッド

PBR=宛先アドレス意外の条件を使って次ホップを決めること
インラインルーテッド=UTMがIPを持ちL3ホップとして経路上にはいること
(L2の場合トランスペアレントorブリッジインライン)

・例

LAN3がWAN、今回はLAN1-LAN2の間に設置。

ip route default gateway <LAN3> filter 101 102 111 112 113 114 115 116 gateway <UTM-LAN> keepalive 1 gateway <LAN3> weight 0

・前提

※gateway … filter N …
Nの条件に合うものものはこのgatewayを使えという意味。

ip route に並んだgatewayは指定がなければ分散する。weightは分散比率。
weight 0 = 他が使える限り使わない。
keepalive 1(監視定義の番号) = 生きている間だけつかえる。

ip route default … ルーティング判定のときだけ参照される。ルータがnext-hop を選ぶのは転送されるユニキャストに対してだけ。ブロードキャストはそもそもルータがセグメント外へ転送しない。

・設定

gateway <LAN3> filter 101 102 111-116
※①VPN系とUTM発だけ直WAN

gateway <UTM> keepalive 1
※②①に外れた”通常通信 全部”をUTMへ
生きている限り一致する(keepalive 1)

gateway <LAN3> weight 0
※③さらに残り全部（＝fail-open）
keepaliveで失敗した最後

・フィルタ設定

構文は
ip filter <番号> <動作> <送信元> <宛先> <プロトコル>

※UTMのWAN脚が送信元 = 検査後の戻り
ip filter 101 pass <UTM-WAN> * * *

※UTMのLAN脚が送信元 = UTM自身の通信
(ほとんど存在しないはずなので保険)
ip filter 102 pass <UMT-LAN> * * *

※PPTP
ip filter 111 pass * * tcp 1723
ip filter 112 pass * * gre

※IKE(拠点間VPN)
ip filter 113 pass * * udp 500
ip filter 114 pass * * esp

※NAT-T(拠点間VPN)
ip filter 115 pass * * udp 4500

※L2TP
ip filter 116 pass * * udp 1701

※監視定義
ip keepalive 1 icmp-echo 10 5 UTM-LAN

※拠点間VPNはこのように直指定も必要
ip route <対向IPアドレス> gateway <ISP Default Gateway>
ip route <対向IPアドレス> gateway pp 1