FAQ
統計分析
統計学の考え方や発想
「統計学の考え方や発想」を身につけることは
- データを取得したときに最初にすべきこと
- データ解析で意識しておくべきこと
- 結果を解釈するときに肝に銘じておきたいこと
へ繋がってきます．
分析コミュニケーション
分析コミュニケーションとは「課題を起点に，データと論理に基づいて洞察を導き，それを意思決定者に理解・納得可能な形で伝達する一連のプロセス」のこと
- \(N\) 個の観測値 \(\{\pmb x_n\}\) と対応する目標値 \(\{t_n\}\) からなる訓練データ集合が与えられたとき，新しい \(\pmb x\) に対する \(t\) を予測すること
- それぞれの \(\pmb x\) の値に対する \(t\) の値の不確かさを表すたのに予測分布 \(p(t\vert \pmb x)\) をモデル化すること
基底関数を用いた線形モデル
- パラメータに関して線形であり解析が容易な一方，入力変数に関しては非線形という特徴がある
正則化ペナルティ項はログスケール
- 正則化項 \(\lambda \|\pmb w\|^2\) の係数 \(\lambda\) は，\(\ln \lambda\) のスケール（ログスケール）で探索・表示するのが一般的
- \(\lambda\) の影響はオーダーで効く(1→10の影響と10→19の影響は異なる)
- PRML では \(\ln \lambda\) を横軸にとってテスト誤差や係数の変化をプロットしている（例：PRML Figure 1.8）
Machine Learning
LLM
Math
\[ \begin{align} \vert X \vert \leq 1 + X^2 \end{align} \]
定義 1 \(L_p\)ノルム
\(1 \leq p < \infty\) とする．ベクトル \(\boldsymbol{x} = (x_1, x_2, \ldots, x_n)^\top \in \mathbb{R}^n\) に対して，
\[ \|\boldsymbol{x}\|_p = \left(\sum_{i=1}^{n} |x_i|^p\right)^{1/p} \]
を \(L_p\) ノルム（\(p\)-ノルム）という．特に，
- \(p = 1\): \(\|\boldsymbol{x}\|_1 = \sum_{i=1}^{n} |x_i|\)（マンハッタンノルム）
- \(p = 2\): \(\|\boldsymbol{x}\|_2 = \sqrt{\sum_{i=1}^{n} x_i^2}\)（ユークリッドノルム）
- \(p = \infty\): \(\|\boldsymbol{x}\|_\infty = \max_{1 \leq i \leq n} |x_i|\)（上限ノルム）
定義 2 距離空間
集合 \(X\) の任意の２つの要素 \(x, y\) に対して実数値関数 \(d(x, y)\) が定義され，次の三条件
\[ \begin{aligned} (1)\quad\;& d(x,y) \ge 0 \quad\quad\text{等号は} x = y \text{のとき}\\ (2)\quad\;& d(x,y) = d(y,x) \\ (3)\quad\;& d(x,z) \le d(x,y) + d(y,z) \end{aligned} \]
が成り立つとき，\(d\) を \(X\) 上の距離(metric)といい，組 \((X, d)\) を距離空間(metric space)という
Linux
プログラムが動作する根本的仕組み
メモリにロードされたマシン語のプログラムが，CPUによって解釈・実行され，それによってコンピューターというシステム全体の制御やデータの演算が行われる
Debian形式パッケージとRPM
- Linuxではパッケージ（実行ファイル＋ライブラリ＋設定ファイル+マニュアル）という単位でソフトウェアを管理
- DebianやUbuntuではDebian形式パッケージ
- Red Hat, CentOS, DeforaではRPM形式
- Linuxはディストリビューションに応じてシステテムライブラリが異なり，それに起因する依存関係のため，それぞれのパッケージを別のプラットフォームで利用することは基本できません(Flatpakという仕組みはある)
apt install --no-install-recommends package のすすめ
- Dependsは入るが，Recommendsはインストールしない
- Docker環境や分析環境では，不要パッケージ排除，管理対象を減らす，セキュリティリスク低減という観点から基本的には使用することを推奨
- GUIデスクトップでは厳密にオプション付与すべきとは考えない
古い Fedora Coreでは rhgb quiet 3 と知っていするとCUI環境でのログイン画面が表示されますが，これはSysV initのrunlevelの指定に対応しています．
rhgb: Red Hat Graphical Bootquiet: カーネルのログ出力量を減らすオプション3: SysV init における マルチユーザーモード（ネットワーク有効・GUIなし） を指定
| runlevel | 意味 |
|---|---|
| 0 | halt（電源断） |
| 1 | single user mode（保守用, rootのみ） |
| 2 | ネットワークなしのmulti-user |
| 3 | multi-user + network（CUI） |
| 4 | 未定義 |
| 5 | multi-user + network + X（GUI） = グラフィカルログインによるマルチユーザーモード |
| 6 | システムの再起動(reboot) |
| コマンド | 役割 | 即時影響 | 起動時の状態への影響 | 主な用途 |
|---|---|---|---|---|
start |
サービスを起動 | 起動する | なし | 手動でサービスを立ち上げる |
stop |
サービスを停止 | 停止する | なし | 一時的にサービスを止める |
restart |
サービスを再起動 | 停止→起動 | なし | 設定変更後の再起動 |
reload |
設定を再読み込み | 再起動せず反映 | なし | 設定のみ反映（対応サービスのみ） |
enable |
自動起動を有効化 | なし | 起動時に自動起動 | サーバー起動時に常に起動させる |
disable |
自動起動を無効化 | なし | 起動時に起動しない | 常駐不要なサービスを外す |
環境構築
バックアップと復元テスト
- バックアップは リストアできて初めて完成．定期的にダミー環境へ復元テストを行う
バックアップの種類
「いつ何を取るか」という観点では，バックアップは以下の4種類に大別される．運用ではフル + 増分（または差分）の組み合わせが基本で，復元手順の単純さとストレージ消費・取得時間のトレードオフで設計する．
| 種類 | 取得対象 | 取得時間/容量 | リストア手順 | 代表ツール |
|---|---|---|---|---|
| フル (Full) | 対象すべて | 最も長く・大きい | フル1本だけで復元可 | tar, dd, rsync, borg create |
| 増分 (Incremental) | 直前のバックアップからの差分 | 最も短く・小さい | フル + すべての増分を順に適用 | tar -g(GNU listed-incremental), rsync --link-dest, borg, restic |
| 差分 (Differential) | 直近フルからの差分 | 増分より大きく・フルより小さい | フル + 最新の差分1本 | rsync --compare-dest, dump -1 |
| スナップショット (Snapshot) | ある時点のFS/ボリューム状態 (CoW) | ほぼ瞬時・容量は変化分のみ | スナップショットをマウント or rollback | LVM snapshot, Btrfs/ZFS snapshot, EBS snapshot, docker volume snapshot |
フル / 増分 / 差分の関係
- フルは単独で完結するが容量・時間コストが大きいので，週次や月次など低頻度で取得するのが定石
- 増分は前回 (フル or 増分) との差分のみを記録するため最も軽量．ただし どれか1本でも欠落すると以降の復元が破綻する
- 差分は常に「最後のフル」との差分を取り続ける．日が経つほど膨らむが，リストアは「フル + 差分1本」だけで済むので運用が単純
borg/resticは内部的に重複排除 (deduplication)を行うため，ユーザから見ればすべて「フル」だが容量効率は増分相当になる
スナップショットはバックアップではない
- LVM/Btrfs/ZFS のスナップショットは 同一ストレージ上のCoW参照であり，物理障害が起きると元データもろとも失われる
- 「作業前のロールバックポイント」や「整合性のある状態で
tar/rsyncを走らせるための一時凍結」として使うのが本来の用途 - 真のバックアップにするには，スナップショットを別ストレージや別ホストへ転送する必要がある (
btrfs send | btrfs receive,zfs send | zfs receive, EBS snapshot copy など)
Claude Code
10人の開発者がいたら，エージェントを正しく使えているのは3人くらい．残りはslopを作っている
Haikuなどの安価なモデルの出番として
- 要約
- コード探索
- 翻訳
など最高精度が必須ではないタスクに対して割り当てる
Opus vs Codex
- Opus: thinkingはあまり行わず，高速に質の高い回答を生成．知っているパターンに対して得意
- Codex: 大量のthinkingを行う傾向がある．新しい問題，見たことのない問題に対して，ファーストプリンシプルから推論ができる
領域とモデル
- フロントエンド領域では，技術の変化が速く，知識カットオフが新しいモデルほど良い
| 役割 | 説明 |
|---|---|
| コンテキスト管理 | OSにおけるメモリ管理に相当．コンテキストウィンドウの使用量監視，要約，圧縮など |
| ツール実行管理 | OSのI/O管理に相当．エージェントが使えるツールを管理し，検索・コード実行・API呼び出しなどのアクセス制御や実行結果の受け渡しを行う |
| タスク計画 | OSのプロセス計画に相当．ユーザーの依頼を複数のサブタスクへ分解し，実行順序や依存関係を管理して目標達成までのワークフローを構築 |
上記の3つの役割は，いずれもAIモデルの中ではなく，外で行われる処理
skill の配置場所
skill をどこに置くかで利用できるユーザの範囲が決まる．
| レベル | パス | 適用範囲 |
|---|---|---|
| エンタープライズ | (managed settings 参照) | 組織内のすべてのユーザ |
| パーソナル | ~/.claude/skills/<skill-name>/SKILL.md |
自分のすべてのプロジェクト |
| プロジェクト | .claude/skills/<skill-name>/SKILL.md |
そのプロジェクトのみ |
| プラグイン | <plugin>/skills/<skill-name>/SKILL.md |
プラグインが有効化されている場所のみ |
名前衝突時の優先順位
- 同じ名前の skill が複数レベルに存在する場合，エンタープライズ > パーソナル > プロジェクト の順で上書きされる
- プラグイン由来の skill は
<plugin-name>:<skill-name>という名前空間を持つため，他レベルとは衝突しない .claude/commands/配下のコマンドファイルも同じ仕組みで動作するが，skill と command が同じ名前を持つ場合は skill が優先される
Python分析環境
プログラミング
- プログラミングとは，コンピューターにユーザーの考えを実行可能な形で伝える作業のことをいう
- 単にコードを書くことではなく，「何をしたいか」を整理し，「実行可能な形」で処理を構造化することが重要
エージェントAiの登場により，人間が詳細な処理手順を書く，というプログラミングの側面の比重は小さくなりつつありますが，
- 「何を実現したいか」を与えることは依然として必要であり，根本である「コンピューターにユーザーの考えを伝える」という本質は変わらない．
また，
- 「何を実現したいか」というゴール定義
- エージェントAIとの協調における Discernment（評価・判断）
- AI が生成した手順や結果の妥当性検証やそれに基づく意思決定
には，人間側が引き続き，アルゴリズム・データ構造・システム構成・問題分解などを理解していることが重要です．
man vs help
外部コマンドの公式マニュアル表示としての man と，プログラム内部でのマニュアル表示の実装としての --help という違いもありますが
manは 仕様としての正確さ（何を保証するか）--helpは 実装としての正確さ（今このバイナリで何が使えるか）
という違いがあります．--help は
- 実装から直接出力されるため，存在しないオプションは出ない
- コード変更と同時に更新される
という特徴があるため，「実装時の制約や使用バグを放置してコーディングが進む事でコードが正となり，実装の「意図」が文書的に失われる」という事象が，man と --help の内容の差分として現れることがあります．
- 原因探索より先に，問題の型を固定する
- 不具合発生時は，症状をカテゴリのどれかに当てはめてから対処に進む
- 「動かない」「効かない」のような曖昧な記述で深追いしない：まず分類してから具体策へ
正規表現
- ワイルドカード（globパターン）はシェルでのファイル名マッチングに使用
- 正規表現はテキスト内のパターンマッチングに使用
| 項目 | ワイルドカード（glob） | 正規表現 |
|---|---|---|
| 主な用途 | シェルでのファイル名・パス指定 | テキスト検索・置換（grep, sed, etc.） |
* の意味 |
0文字以上の任意の文字列 | 直前の文字の0回以上の繰り返し |
. の意味 |
ただのドット文字 | 任意の1文字（メタ文字） |
? の意味 |
任意の1文字 | 直前の文字の0または1回 |
| 使用例 | ls *.txtcp file?.log /tmp/ |
grep "a.*b" file.txtsed 's/[0-9]\+/X/g' |
具体例
# ワイルドカード（シェル）
ls *.txt # file1.txt, data.txt などにマッチ
rm test?.log # test1.log, testA.log などにマッチ
# 正規表現（grep）
grep "test.*log" file.txt # "test" と "log" の間に任意の文字列
grep "file[0-9]+" file.txt # "file" の後に1つ以上の数字シェル
シェルには 内部コマンド（builtin） と 外部コマンド の2種類があります．
| 種類 | 例 |
|---|---|
| 内部コマンド | cd, export, set, echo, read |
| 外部コマンド | ls, cp, mv, grep, awk |
内部コマンド
- シェルの本体が持っているコマンド
- シェル自身が処理するコマンドで，外部プログラムを起動しない
- 高速で，カレントディレクトリ・変数・ジョブ状態などシェル自身の状態を直接変更できる
外部コマンド - /bin や /usr/bin などに存在する実行ファイルで，シェルは fork/exec によって別プロセスとして実行． - 多くの場合，「実行ファイル名 = コマンド名」
判定方法
内部コマンドかどうかは type で確認できます(which でも可能)
$ type cd
cd is a shell builtin
$ type cp
cp is /usr/bin/cpクォートの種類
特殊文字の意味を打ち消す（quoting）方法は3種類
| 記号 | 意味 |
|---|---|
\ |
直後の1文字のみ展開を抑止 |
'...' |
中の すべての文字 の展開を抑止 |
"..." |
$・`・! を 除く すべての文字の展開を抑止 |
$… 変数参照（例：$HOME）`… コマンド置換（例：`date`）!… ヒストリ展開（!!,!数字等）．末尾の!は展開対象にならないためクオート不要
ドキュメント
OSSライセンス
| ライセンス | OSI分類 | 個人利用 | 組織内利用 | 著作権表示の保持 | 免責事項の保持 | 特徴 |
|---|---|---|---|---|---|---|
| GPL | コピーレフト（強） | 適用外 | 適用外 | 必須 | 必須 | バイナリを配布する場合は，そのソースコードも公開しなくてはならない |
| Apache License 2.0 | パーミッシブ | 可 | 可 | 必須（NOTICE含む） | 必須 | 特許ライセンス条項あり NOTICE保持が必要 改変箇所は別ライセンスでも配布可能 改変再配布でもソース公開義務なし |
| MIT | パーミッシブ | 可 | 可 | 必須 | 必須 | 著作権表示を残せば再配布・商用利用OK 改変再配布でもソース公開義務なし |
| Mozilla 2.0 | コピーレフト（弱・ファイル単位） | 可 | 可 | 必須 | 必須 | 変更したファイルのみソース公開が必要（file-level copyleft） 単独ソフトの場合は再配布時にソース公開が必要 |