nslookup チートシート

## 1. 基本の書式

```
nslookup [オプション] <調べる名前> [問い合わせ先DNSサーバー]
```

| 部分 | 内容 | 例 |
|---|---|---|
| オプション | レコードの種類の指定やデバッグ表示など | `-type=mx`、`-debug` |
| 調べる名前 | ドメイン名・ホスト名・IPアドレス（**名前の末尾に `.` を付けるのが確実**。3章参照） | `example.com.` |
| 問い合わせ先 | 省略すると、PCに設定されたDNS（ルーターやプロバイダのDNSなど）を使う | `ns1.example.net` |

### 対話モード
引数なしで実行すると、対話モードになります。

| 対話モードのコマンド | コマンドラインでの同等の指定 |
|---|---|
| `set type=mx` | `-type=mx` |
| `set debug` ／ `set nodebug` | `-debug` |
| `server ns1.example.net` | 末尾に問い合わせ先 `ns1.example.net` を指定 |
| `example.com.`（名前だけを入力） | 問い合わせの実行 |
| `set all` | （なし）現在の設定（type、debug、問い合わせ先など）を一覧表示する |
| `exit` | 対話モードの終了 |

---

## 2. よく使うオプション

| オプション | 意味 |
|---|---|
| `-type=<種類>` | レコードの種類を指定する（`-q=<種類>` も同じ）。省略するとA（とAAAA） |
| `-debug` | 実際に送った問い合わせ名（QUESTIONS）、応答の種類、TTLなどの詳細を表示する |
| `-norecurse` | 問い合わせ先に「代わりに調べて」と頼まない（相手のDNSが持っている情報だけを見たいとき） |
| `-timeout=<秒>` | 応答を待つ時間 |

### レコードの種類（`-type=`）

| 種類 | 内容 | 主な用途 |
|---|---|---|
| `a` | 名前 → IPv4アドレス | Webサイトやサーバーの接続先の確認 |
| `aaaa` | 名前 → IPv6アドレス | 同上（IPv6） |
| `mx` | メールの受信先サーバー（優先度付き） | メールがどこに届くかの確認 |
| `txt` | 任意の文字列 | SPF（`v=spf1 …`）、DMARC（`_dmarc.` の下）、ドメインの所有権確認 |
| `ns` | そのドメインを管理するDNSサーバー（向き先） | どのDNSでゾーンが管理されているかの確認 |
| `soa` | ゾーンの管理情報（管理元・シリアル番号・既定値など） | ゾーンの有無、変更の目安 |
| `cname` | 別名 | 別名の参照先の確認 |
| `ptr` | IPアドレス → 名前（逆引き） | IPアドレスがどのサーバーのものかの確認 |
| `any`（`all` も同じ） | 全種類 | **確認には使わない**。DNSサーバーによって返る内容が異なり、最小限の応答（`HINFO RFC8482`）しか返さないものも多い。全レコードの一覧は得られない |

---

## 3. 注意点

### 名前の末尾には `.` を付ける（Windowsの場合）
Windows の `nslookup` は、末尾に `.` のない名前を問い合わせるとき、**まずPCのDNSサフィックス（例：`isp.example.ne.jp`）を補った名前で問い合わせます**。

```
nslookup -type=ns example.com a.dns.jp
→ 実際には example.com.isp.example.ne.jp を問い合わせ、無関係な結果が表示されることがある

nslookup -type=ns example.com. a.dns.jp
→ 意図どおり example.com を問い合わせる
```
（`a.dns.jp`：.jp ドメインを管理するJPRSのDNSサーバー）

- 通常のDNSサーバーに問い合わせた場合は、補った名前が「存在しない」と返り、元の名前で問い合わせ直すので気付きにくい。
- 上位のDNSサーバー（`a.dns.jp` など）は「委任先の案内」を返すため、補った名前の結果がそのまま表示されてしまう。
- 実際に送った名前は、`-debug` の `QUESTIONS:` 欄で確認できる。
- PCに設定されているサフィックスは、`ipconfig /all` の「接続固有の DNS サフィックス」「DNS サフィックス検索一覧」で確認できる（Windowsの場合）。

### レコードの種類を必ず指定する
`-type` を省略するとAレコードとして問い合わせます。たとえばDMARC（TXTレコード）を種類なしで問い合わせると「ない」という結果になり、**設定されていないと誤認**します。

### 問い合わせ先によって結果の意味が変わる

| 問い合わせ先 | 得られるもの |
|---|---|
| 省略（PCのDNS） | キャッシュを含む結果。TTLは**残り時間**（カウントダウンされた値） |
| 権威DNS（そのゾーンを持つDNS） | ゾーンに設定されている**正の値**。TTLは設定値 |
| 上位のDNS（TLDを管理するDNS） | 「このドメインはどのDNSが管理しているか」という委任の情報 |

---

## 4. 出力の読み方
表示の文言は、Windowsの場合のものです。

| 表示 | 意味 |
|---|---|
| `Non-authoritative answer:` | キャッシュDNSからの応答（権威DNSの応答ではない） |
| `auth. answer`（`-debug` のヘッダー） | 権威DNSからの応答 |
| `ttl = 3600 (1 hour)`（`-debug`） | TTL。権威DNSに問い合わせたときは設定値 |
| SOAだけが返る（`primary name server = …` だけ表示） | **その名前・種類のレコードはない**（ゾーン自体はある） |
| `can't find … : Non-existent domain` | その名前自体が存在しない |
| `Query refused` | そのDNSサーバーは、そのドメインを管理していない（または問い合わせを拒否している） |
| `HINFO CPU = RFC8482` | `-type=any` への最小限の応答。全レコードの一覧ではない |
| `??? unknown type 65 ???` | nslookupが表示に対応していない種類のレコード（例：65はHTTPSレコード） |
| `default TTL = …`（SOAの表示） | SOAの最後の項目（MINIMUM）。現在の規格では**ネガティブキャッシュの時間**（「存在しない」という応答を保持する時間） |
| 権威DNSなのにTTLが問い合わせのたびに減る | 参照先の値を返すエイリアス型（CNAMEフラットニング）のレコードと考えられる |

---

## 5. 用途別コマンド集

### 5-1. ドメインを管理しているDNSサーバーはどこか（NSレコード）

```
nslookup -type=ns example.com.
nslookup -type=ns example.jp. a.dns.jp
```
- 上位のDNSに問い合わせると、「どのDNSサーバーがこのドメインの設定（ゾーン）を管理しているか」という登録内容（委任）が分かる。**ここに出るDNSサーバーだけが外部から参照される。**
- `a.dns.jp`：.jp を管理するJPRSのDNSサーバー（a〜hの8台）。.com・.net の場合は `a.gtld-servers.net` など。
- TLDを管理するDNSサーバーの一覧は、次のコマンドで確認できる。
```
nslookup -type=ns jp.
nslookup -type=ns com.
```

### 5-2. DNSサーバーがそのドメインの設定（ゾーン）を持っているか（SOAレコード）

```
nslookup -type=soa example.com. ns1.example.net
```
- SOAが返れば、そのDNSサーバーはゾーンを持っている。
- シリアル番号は、日付形式（例：`2024010500`）で付けられていることが多く、最終変更の目安になる。

### 5-3. メールがどのサーバーに届くか（MXレコード）

```
nslookup -type=mx example.com.
nslookup -type=mx example.com. ns1.example.net
```
- 優先度（preference）の値が小さいサーバーから順に使われる。

### 5-4. どのサーバーからのメール送信が許可されているか（SPF：TXTレコード）

```
nslookup -type=txt example.com. ns1.example.net
```
- 返ってきたTXTのうち、`v=spf1` で始まるものがSPF。**1本だけ**であることを確認する（2本以上あると無効）。
- 例：`v=spf1 include:spf.example.net ~all` は、`spf.example.net` で許可された送信元を許可し、それ以外は「怪しいが受け取ってよい」（`~all`）という意味。`-all` の場合は「拒否してよい」。
- 参考：include 先の名前のTXTを問い合わせると、許可されている送信元（IPアドレスなど）を見られる。
```
nslookup -type=txt spf.example.net.
```

### 5-5. 認証に失敗したメールの扱いが指定されているか（DMARC：TXTレコード）

```
nslookup -type=txt _dmarc.example.com. ns1.example.net
```
- **`-type=txt` を必ず指定する**。
- `p=none`（何もしない）、`p=quarantine`（迷惑メール扱い）、`p=reject`（拒否）のいずれかが指定されている。

### 5-6. 送信メールの電子署名を検証する公開鍵があるか（DKIM：TXTレコード）

```
nslookup -type=txt <セレクタ>._domainkey.example.com.
```
- セレクタ名が分からないと照会できない。送信側の設定や、受信したメールのヘッダー（`DKIM-Signature` の `s=`）で確認する。

### 5-7. レコードがどれくらいの時間キャッシュされるか（TTL）

```
nslookup -debug -type=mx example.com. ns1.example.net
```
- 権威DNSに `-debug` 付きで問い合わせると、`ttl =` に設定値が表示される。
- 何度か問い合わせて値が変わらなければ固定の設定値、減っていく場合はキャッシュの残り時間か、エイリアス型のレコード。

### 5-8. 名前とIPアドレスの対応（Aレコード／逆引きのPTRレコード）

```
nslookup -type=a mail.example.com.
nslookup -type=ptr 10.2.0.192.in-addr.arpa.
nslookup 192.0.2.10                       ← IPアドレスを渡すと逆引きになる
```
- 逆引きの名前は、IPアドレスを逆順に並べて `.in-addr.arpa.` を付けたもの（192.0.2.10 → `10.2.0.192.in-addr.arpa.`）。

### 5-9. 実際にどの名前で問い合わせたか（補完の確認）

```
nslookup -debug -type=ns example.com a.dns.jp
```
- `QUESTIONS:` 欄に表示される名前が、実際に問い合わせた名前。サフィックスが補われていないかを確認できる（3章参照）。

### 5-10. DNSの変更がすべての管理サーバーに反映されたか

```
nslookup -debug -type=mx  example.com. ns1.example.net
nslookup -debug -type=mx  example.com. ns2.example.net
nslookup -debug -type=txt example.com. ns1.example.net
nslookup -debug -type=txt example.com. ns2.example.net
```
- 権威DNSが複数ある場合は、**すべてに問い合わせて**同じ新しい値が返ることを確認する（外部からは、どの権威DNSに問い合わせが行くか分からないため）。
- PCのDNS（問い合わせ先を省略）では、TTLが切れるまで古い値が返ることがある。

---

## 6. 補足：WHOIS（ドメインの登録情報）
WHOISのコマンドは、OSによっては標準で入っていない（Windowsでは、Sysinternals の Whois を別途導入する）。次のWebサービスでも確認できる。
- .jp ドメイン：JPRS WHOIS（[https://whois.jprs.jp/](https://whois.jprs.jp/)）
- .com・.net・.org などのgTLD：ICANN Lookup（[https://lookup.icann.org/](https://lookup.icann.org/)）。ドメイン名の国際的な管理団体（ICANN）の公式ページ
- その他の国別ドメイン（.uk、.de など）：IANA WHOIS（[https://www.iana.org/whois](https://www.iana.org/whois)）でTLDを検索すると、そのTLDを管理するレジストリとWHOISサーバーが分かる

CVP分析グラフ

## CVPグラフ

## 損益構造の恒等式
| 区分 | 式 |
|---|---|
| 売上 | 変動費 + 固定費 + 利益 = 費用 + 利益 = 変動費 + 限界利益 |
| 費用 | 変動費 + 固定費 = 売上 − 利益 |
| 変動費 | 売上 × 変動費率 = 売上 − 限界利益 = 費用 − 固定費 |
| 固定費 | 費用 − 変動費 = 限界利益 − 利益 |
| 利益 | 売上 − 費用 = 限界利益 − 固定費 = 売上 × 限界利益率 − 固定費 |
| 限界利益 | 売上 − 変動費 = 固定費 + 利益 = 売上 × 限界利益率 |
| 変動費率 | 変動費 ÷ 売上 = 1 − 限界利益率 |
| 限界利益率 | 限界利益 ÷ 売上 = 1 − 変動費率 |

## 損益の構造図

Linux ネットワーク／Wi-Fi コマンド チートシート

## 0. コマンドの役割

| コマンド | 主な用途 | 備考 |
|---|---|---|
| `ip` | インターフェース、IPアドレス、ルート、MACアドレスの確認・一時操作 | `iproute2`に含まれる |
| `nmcli` | NetworkManagerの接続・プロファイル管理 | 設定を永続化できる |
| `iw` | Wi-Fiデバイス、接続先、周波数、電波情報の確認 | 無線LANの低レベル情報 |
| `rfkill` | Wi-Fiなどの無線機能のブロック状態確認 | ハード／ソフトブロックを確認 |
| `lsusb` | USBデバイスの認識確認 | USB Wi-Fiドングルの確認 |
| `ethtool` | NICのドライバーやリンク情報の確認 | 無線では主にドライバー確認に使用 |

> 対象: Debian/Ubuntu系およびRHEL/Rocky/AlmaLinux系。`nmcli`はNetworkManager使用環境が前提です。

## 1. インターフェース一覧

```bash
ip link
ip -br link
nmcli device status
iw dev
```

## 2. USB Wi-Fiドングルの認識確認

```bash
lsusb
sudo dmesg | grep -iE 'usb|wifi|wlan|wireless|firmware'
sudo journalctl -k | grep -iE 'usb|wifi|wlan|wireless|firmware'
sudo ethtool -i wlan1
readlink -f /sys/class/net/wlan1/device/driver
```

## 3. MACアドレスの確認

```bash
ip link show wlan1
cat /sys/class/net/wlan1/address
nmcli -g GENERAL.HWADDR device show wlan1
ip -br link
```

## 4. IPアドレスの確認

```bash
ip address
ip addr show dev wlan1
ip -br addr
nmcli device show wlan1
nmcli -g IP4.ADDRESS,IP4.GATEWAY,IP4.DNS device show wlan1
```

## 5. Wi-Fiアクセスポイントの検索

```bash
nmcli device wifi rescan
nmcli device wifi list
nmcli device wifi list ifname wlan1
nmcli -f IN-USE,SSID,BSSID,CHAN,FREQ,SIGNAL,SECURITY device wifi list ifname wlan1
sudo iw dev wlan1 scan
sudo iw dev wlan1 scan | grep -E 'BSS |SSID:|freq:|signal:'
```

## 6. Wi-Fiへ接続

### SSIDを指定

```bash
nmcli device wifi connect "SSID" password "PASSWORD" ifname wlan1
```

パスワードをコマンド履歴へ残したくない場合:

```bash
nmcli --ask device wifi connect "SSID" ifname wlan1
```

### BSSIDを指定

```bash
nmcli device wifi connect "AA:BB:CC:DD:EE:FF" password "PASSWORD" ifname wlan1
```

SSIDとBSSIDを両方指定:

```bash
nmcli device wifi connect "SSID" bssid "AA:BB:CC:DD:EE:FF" password "PASSWORD" ifname wlan1
```

### 既存プロファイルを有効化

```bash
nmcli connection up "接続名" ifname wlan1
```

## 7. 接続中のWi-Fi情報

```bash
iw dev wlan1 link
nmcli device show wlan1
nmcli -f IN-USE,SSID,BSSID,CHAN,FREQ,SIGNAL device wifi list ifname wlan1
```

`iw dev wlan1 link`の主な項目:

- `Connected to`: 接続中のBSSID
- `SSID`: 接続中のSSID
- `freq`: 中心周波数
- `signal`: 受信信号強度
- `tx bitrate`: 送信リンク速度

## 8. チャネル／周波数の確認

```bash
iw dev wlan1 link
iw dev wlan1 info
nmcli -f IN-USE,SSID,BSSID,CHAN,FREQ device wifi list ifname wlan1
```

### 代表的な周波数とチャネル

| 周波数 | チャネル |
|---:|---:|
| 2412 MHz | 1 |
| 2437 MHz | 6 |
| 2462 MHz | 11 |
| 5180 MHz | 36 |
| 5200 MHz | 40 |
| 5220 MHz | 44 |
| 5240 MHz | 48 |
| 5500 MHz | 100 |
| 5520 MHz | 104 |
| 5540 MHz | 108 |
| 5560 MHz | 112 |

## 9. 内蔵Wi-FiからUSB Wi-Fiへ切り替える

例:

- 内蔵Wi-Fi: `wlan0`
- USB Wi-Fi: `wlan1`

```bash
nmcli device disconnect wlan0
nmcli device wifi connect "SSID" password "PASSWORD" ifname wlan1
nmcli device status
iw dev wlan1 link
ip route
```

内蔵Wi-Fiを一時停止:

```bash
sudo ip link set wlan0 down
```

元に戻す:

```bash
sudo ip link set wlan0 up
```

NetworkManagerの管理対象外にする:

```bash
sudo nmcli device set wlan0 managed no
sudo nmcli device set wlan0 managed yes
```

## 10. 接続プロファイルの管理

```bash
nmcli connection show
nmcli connection show --active
nmcli connection show "接続名"
```

プロファイルを特定インターフェースへ固定:

```bash
nmcli connection modify "接続名" connection.interface-name wlan1
```

BSSIDを固定／解除:

```bash
nmcli connection modify "接続名" 802-11-wireless.bssid "AA:BB:CC:DD:EE:FF"
nmcli connection modify "接続名" 802-11-wireless.bssid ""
```

自動接続と優先度:

```bash
nmcli connection modify "接続名" connection.autoconnect yes
nmcli connection modify "接続名" connection.autoconnect-priority 100
```

設定反映:

```bash
nmcli connection down "接続名"
nmcli connection up "接続名"
```

## 11. Wi-Fi無線機能の有効／無効

```bash
nmcli radio wifi
nmcli radio wifi on
nmcli radio wifi off
rfkill list
sudo rfkill unblock wifi
sudo rfkill unblock all
```

## 12. インターフェースの有効／無効

```bash
sudo ip link set wlan1 down
sudo ip link set wlan1 up
nmcli device disconnect wlan1
nmcli connection up "接続名" ifname wlan1
```

## 13. デフォルトルートの確認

```bash
ip route
ip route get 8.8.8.8
ip -6 route
```

例:

```text
default via 192.168.1.1 dev wlan1 proto dhcp metric 600
```

この場合、デフォルト通信は`wlan1`を使用します。

## 14. インターフェースの優先順位

Linuxは通常、デフォルトルートの`metric`が小さい経路を優先します。

```bash
ip route
nmcli connection modify "USB-WiFi" ipv4.route-metric 100
nmcli connection modify "Internal-WiFi" ipv4.route-metric 600
nmcli connection modify "USB-WiFi" ipv6.route-metric 100
nmcli connection modify "Internal-WiFi" ipv6.route-metric 600
nmcli connection down "USB-WiFi"
nmcli connection up "USB-WiFi"
```

## 15. Wi-Fiの対応周波数・チャネル確認

```bash
iw phy
iw phy phy0 info
iw list
```

確認できる主な項目:

- 対応周波数・使用可能チャネル
- 無効化されたチャネル
- 対応インターフェースモード
- HT／VHT／HE／EHT対応状況
- 対応チャネル幅

## 16. リージョン／規制ドメイン

```bash
iw reg get
sudo iw reg set JP
iw reg get
iw list
```

> 恒久設定方法はディストリビューションと無線ドライバーによって異なります。

## 17. 通信状態の確認

```bash
ip -s link show wlan1
ip route
ping -c 4 192.168.1.1
ping -c 4 8.8.8.8
ping -c 4 example.com
nmcli general status
```

## 18. NetworkManagerログの確認

```bash
systemctl status NetworkManager
sudo journalctl -u NetworkManager -b
sudo journalctl -u NetworkManager -f
sudo journalctl -u NetworkManager -b | grep -iE 'wifi|wlan|802-11|supplicant'
systemctl status wpa_supplicant
```

## 19. 変更前後の確認セット

### 変更前

```bash
ip -br link
ip -br addr
ip route
nmcli device status
nmcli connection show --active
iw dev
iw dev wlan1 link
```

### 変更後

```bash
nmcli device status
nmcli connection show --active
iw dev wlan1 link
ip addr show dev wlan1
ip route
ip route get 8.8.8.8
```

## 20. トラブルシューティング基本フロー

### 1. USBデバイスとして認識されているか

```bash
lsusb
```

### 2. インターフェースが作成されているか

```bash
ip -br link
iw dev
```

### 3. ドライバー／ファームウェアエラーがないか

```bash
sudo journalctl -k -b | grep -iE 'firmware|wifi|wlan|wireless|usb|error|failed'
```

### 4. 無線機能がブロックされていないか

```bash
rfkill list
nmcli radio
```

### 5. NetworkManagerが管理しているか

```bash
nmcli device status
```

### 6. アクセスポイントを検出できるか

```bash
nmcli device wifi rescan ifname wlan1
nmcli device wifi list ifname wlan1
```

### 7. 接続できているか

```bash
iw dev wlan1 link
```

### 8. IPアドレスが割り当てられているか

```bash
ip addr show dev wlan1
```

### 9. デフォルトルートがあるか

```bash
ip route
```

### 10. 経路、外部疎通、DNSを切り分ける

```bash
ip route get 8.8.8.8
ping -c 4 8.8.8.8
ping -c 4 example.com
```

## 21. よく使うワンライナー

Wi-Fiインターフェース名:

```bash
iw dev | awk '$1=="Interface"{print $2}'
```

MACアドレス:

```bash
cat /sys/class/net/wlan1/address
```

接続中のBSSID:

```bash
iw dev wlan1 link | awk '/Connected to/{print $3}'
```

接続中のSSID:

```bash
iw dev wlan1 link | sed -n 's/^[[:space:]]*SSID: //p'
```

現在の周波数:

```bash
iw dev wlan1 link | awk '/freq:/{print $2 " MHz"}'
```

デフォルトルートで使用中のインターフェース:

```bash
ip route show default | awk '/default/{print $5}'
```

Wi-Fi接続情報をまとめて確認:

```bash
printf '%s\n' '=== Device ===' &&
nmcli device status &&
printf '%s\n' '=== Link ===' &&
iw dev wlan1 link &&
printf '%s\n' '=== Address ===' &&
ip -br addr show wlan1 &&
printf '%s\n' '=== Route ===' &&
ip route
```

## 注意事項

- `ip link set ... down`による変更は一時的です。
- `nmcli connection modify`は保存された接続プロファイルを変更します。
- `device`はインターフェースの現在状態、`connection`はNetworkManagerの設定プロファイルです。
- SSH接続中に使用中のインターフェースを停止すると、接続が切断されます。
- インターフェース名は`wlan0`、`wlp2s0`、`wlx...`など環境によって異なります。
- BSSID固定中は別のアクセスポイントへのローミングが制限されます。
- 実行前に対象インターフェース名と接続プロファイル名を確認してください。

Claude の共有範囲まとめ（claude.ai / デスクトップ / ターミナル / Web）

> 調査日: 2026-09-29
> 出典: Anthropic 公式ドキュメント（末尾の参考リンク）。

---

## 基本の考え方

分ける軸は「Web / デスクトップ / ターミナル」ではなく、**どこに保存されるか**。

1. **アカウント（クラウド）に保存** → どの端末からでも見える
2. **PC のローカル（`~/.claude/` 配下）に保存** → そのPCの中ならターミナルとデスクトップで共有される。別のPCには同期されない
3. **Git リポジトリに保存** → push / pull で共有される

---

## ① claude.ai チャット

| 項目 | Web / デスクトップ(Chat) / モバイル | Claude Code |
|---|---|---|
| チャット履歴 | ✅ 同期 | ❌ 見えない |
| Projects（チャット用）、メモリ、カスタム指示、スタイル | ✅ 同期 | ❌ 読み込まれない |
| コネクタ（claude.ai/customize/connectors で追加） | ✅ 同期 | ✅ 同じアカウントでログインすれば使える |

- チャットと Claude Code は別の製品として扱われる。チャットの内容や claude.ai のメモリは Claude Code に引き継がれない。

---

## ② Claude Code のセッション

| 種類 | 保存場所 | 他の環境から見えるか |
|---|---|---|
| ターミナル(CLI) | そのPCの `~/.claude/projects/...jsonl` | 同じPCなら `claude --resume` や `/resume` で再開できる。別のPCからは基本的に見えない |
| デスクトップ版 Code タブ（ローカル） | そのPC | ほかのPCや Web からは見えない |
| Claude Code on the web（クラウド） | Anthropic のクラウド | ✅ Web（claude.ai/code）、モバイル、デスクトップから見える。`claude --teleport` でターミナルに取り込める |
| Remote Control | ローカルで動いているセッションのまま | ローカルセッションをスマホやブラウザから操作する仕組み。PCの電源が切れたりスリープしたりすると止まる |

- ローカルセッションを別の端末から扱いたいとき → **クラウドセッション** にするか **Remote Control** を使う

---

## ③ 設定・メモリ・スキル・MCP（Claude Code）

| 項目 | 場所 | 同じPC内（CLI ⇔ デスクトップ） | 別のPC |
|---|---|---|---|
| ユーザー用 CLAUDE.md、settings.json | `~/.claude/` | ✅ 共有 | ❌ 同期なし（自分でコピーする） |
| 自動メモリ（auto memory） | `~/.claude/projects//memory/` | ✅ 共有 | ❌ 同期なし |
| ユーザー用スキル | `~/.claude/skills/` | ✅ 共有 | ❌ 同期なし |
| ユーザー/ローカル用 MCP | `~/.claude.json` | ✅ 共有 | ❌ 同期なし |
| プロジェクト用 CLAUDE.md、`.claude/settings.json`、`.claude/skills/`、`.mcp.json` | リポジトリ | ✅ 共有 | ✅ Git 経由で共有 |
| `settings.local.json`、`CLAUDE.local.md` | リポジトリ（Git の管理外） | ✅ 共有 | ❌ 同期なし |

---

## 実務上のポイント

- デスクトップ版の Code タブも、CLI と同じ `~/.claude` を使う。同じPCなら、メモリ、スキル、設定は共通。
- **どこでも使いたいスキルや指示はリポジトリ側（`.claude/skills/`、`CLAUDE.md`）に置く**。別のPCでもクラウドセッションでも、clone すれば同じように使える。
- クラウドセッションはリポジトリを clone して動くため、ローカルにしかない `~/.claude` の自動メモリやユーザー用スキルは読み込まれない。

---

## 参考

- [Sessions](https://code.claude.com/docs/en/sessions.md)
- [Claude Code on the web](https://code.claude.com/docs/en/claude-code-on-the-web.md)
- [Remote Control](https://code.claude.com/docs/en/remote-control.md)
- [Desktop](https://code.claude.com/docs/en/desktop.md)
- [Memory](https://code.claude.com/docs/en/memory.md)
- [Settings](https://code.claude.com/docs/en/settings.md)
- [MCP](https://code.claude.com/docs/en/mcp-quickstart.md)

AWS Transfer Family (SFTP → S3)

## News
[新サービス – AWS Transfer for SFTP – Amazon S3向けフルマネージドSFTPサービス](https://aws.amazon.com/jp/blogs/aws/new-aws-transfer-for-sftp-fully-managed-sftp-service-for-amazon-s3/)

## 全体構成
```
SFTPクライアント(IP指定/Port22)
        │
        ▼
   Elastic IP
        │
        ▼
Transfer Family サーバー (SFTP / VPCエンドポイント)
        │
        ▼
      S3バケット
```

## 構築手順

### 1. Elastic IP を確保
- 新規EIPを1つ取得（対象リージョン）

### 2. サブネット・セキュリティグループ準備
- 既存VPC内の対象AZの**パブリックサブネット**を選択
  - プライベートサブネットの場合、EIP付与不可（NAT経由では不可）
- セキュリティグループ
  - インバウンド: TCP/22、送信元は接続元IPで絞る

### 3. IAMロール作成
- 信頼ポリシー: プリンシパル `transfer.amazonaws.com`
- 許可アクション: `s3:GetObject` `s3:PutObject` `s3:ListBucket` `s3:DeleteObject`
- Resourceは対象バケット/プレフィックスに限定推奨

### 4. S3バケット準備
- 既存流用 or 新規作成
- 複数ユーザー分離が必要ならプレフィックス設計（例: `bucket/user1/`）

### 5. Transfer Family サーバー作成
| 項目 | 設定値 |
|---|---|
| プロトコル | SFTP |
| エンドポイントタイプ | **VPC**（PUBLICだとIP固定不可） |
| VPC | 既存VPC |
| サブネット | 手順2の単一サブネット |
| セキュリティグループ | 手順2のもの |
| アイデンティティプロバイダー | サービスマネージド |
| Elastic IP | サーバー作成時にサブネットと合わせて指定可能（作成後の紐付け作業は不要） |

### 6. ユーザー作成

**事前準備（クライアント側で鍵ペア生成）**
```bash
ssh-keygen -t rsa -b 4096 -f ./transfer_user_key -C "user1"
```
- `transfer_user_key`（秘密鍵）: クライアントが保管
- `transfer_user_key.pub`（公開鍵）: AWS側に登録

**コンソール設定**

| 項目 | 内容 |
|---|---|
| ユーザー名 | 英数字・アンダースコアのみ |
| ロール | 手順3のIAMロール |
| ホームディレクトリタイプ | S3バケット |
| ホームディレクトリ | 下表参照 |
| 制限付き(Restricted) | 有効推奨（指定パス配下のみ表示） |
| SSH公開鍵 | `.pub`ファイルの中身をそのまま貼り付け |

**ホームディレクトリの指定でアップロード先が変わる**

| 設定 | アップロード先 |
|---|---|
| `my-bucket/user1` | `user1/` フォルダ配下 |
| `my-bucket`（プレフィックスなし） | バケット直下 |


- 複数ユーザーで同一バケット直下を共有する場合、ディレクトリ分離はされないためIAMロールでのアクセス制御が唯一の分離手段。誤って他ユーザーのファイルを上書き/削除するリスクがあるため、複数ユーザー運用時はプレフィックス分離推奨。

### 7. 接続確認

**sftpコマンド**
```bash
sftp -i ./transfer_user_key user1@<EIPのIPアドレス>
```
- 初回はknown_hostsの確認プロンプトが出る
- `ls` でホームディレクトリ配下が見えることを確認

**WinSCP等のGUIクライアント**
- WinSCP（PuTTY系エンジン）はPPK形式を要求する場合あり
  - PuTTYgenで「Import key」→「Save private key」で`.ppk`に変換して指定
  - WinSCP 5.x以降はOpenSSH形式の秘密鍵を直接読み込める場合もあるため、まずはそのまま指定してみる

PMが知っておくべき代表的な法則

## 1. QCD（プロジェクトマネジメントの三角形）

品質（Quality）、コスト（Cost）、納期（Delivery）は相互に制約し合う。

- プロジェクト開始時に優先順位を明確化する
- 品質・コスト・納期の変更時は影響分析を行う
- ステークホルダーと優先順位を合意する

---

## 2. コーンの不確実性の円錐

プロジェクト初期の見積りには大きな誤差が存在する。

- 初期見積りを確定値として扱わない
- 要件確定後に再見積りを行う
- 見積りの前提条件を明確にする

---

## 3. ブルックスの法則

遅れているプロジェクトへの安易な増員は、さらに遅延を招く。

- 増員前に遅延原因を分析する
- スコープ削減や優先順位変更を検討する
- 早期にリスクを検知し対処する

---

## 4. パレートの法則（80:20の法則）

成果や問題の大部分は、少数の重要な要因から生じる。

- 重要タスクを特定する
- クリティカルパスを重点管理する
- 障害頻発箇所を優先的に改善する

---

## 5. マーフィーの法則

失敗する可能性があるものはいずれ失敗する。

- 障害発生を前提に計画する
- リスク管理計画を作成する
- バックアップや復旧手順を準備する

---

## 6. パーキンソンの法則

仕事は与えられた時間を使い切るまで膨張する。

- 適切な期限を設定する
- 短いマイルストーンを設ける
- 中間レビューを実施する

---

## 7. 学生症候群

人は締切直前まで作業着手を先送りしやすい。

- 中間マイルストーンを設定する
- 定期的に進捗を確認する
- 早期着手を促す仕組みを作る

---

## 8. コンウェイの法則

システム構造は組織構造を反映する。

- システム設計と組織設計を整合させる
- 責任分界点を明確にする
- 組織横断のコミュニケーションを確保する

---

## 9. リングルマン効果

チーム人数が増えるほど、一人当たりの生産性は低下する。

- 役割と責任を明確にする
- 小規模なチームへ分割する
- 意思決定経路を簡素化する

---

## 10. コミュニケーション経路数

コミュニケーション経路数は n(n-1)/2 で増加する。

例：

- 5人 → 10経路
- 10人 → 45経路
- 20人 → 190経路

- 情報共有ルールを統一する
- 窓口や責任者を明確にする
- チームを適切な規模に分割する

AI導入時の運用ルール・プロンプト設計ガイドライン

## プロンプト設計の原則

### 上流工程（要件定義・基本設計・詳細設計）向け

- 以下の要素で構成する
  - **役割の指定**：どういう立場で回答させるか（例：「業務システム開発経験豊富なシステムアナリスト」）
  - **背景・コンテキスト**：システムの概要・技術スタック・動作原理など前提情報
  - **インプット情報**：そのフェーズで確定した成果物の内容
  - **出力指示**：何をどの形式で生成させるか。以下を明示することが品質向上につながる
    - 確定済み内容と叩き台として追記する内容を区別して出力するよう指示する
    - 出力してほしいものだけでなく出力してほしくないものも明示する
    - 出力形式（表・項目構成など）を具体的に指定する
- プロンプトは単体で完結する情報を持たせる（使用するツールがプロンプト外の文書を参照できない場合、必要な情報はプロンプト内に展開して記載する）

### 製造・テストフェーズ向け

- 以下の要素で構成する
  - **前提・条件**：対象のPR番号・ブランチ・テスト方針など作業の前提となる指定を記載する
  - **作業内容**：タスク固有の実装内容・指示を記載する
  - **参照ファイル**：起点となるファイルを指定し、対象ファイルをAIに特定させる。タスク固有の機能・画面仕様は該当する仕様ファイル（例：docs/配下）の参照を指示する
  - **証跡**：「AGENTS.mdの証跡ルールに従いPRコメントに記載すること」とする
- 一度に全部を頼まず、タスク（動作確認できる単位）で区切る
- AGENTS.mdに共通ルール・制約を記載し、タスク固有の内容はタスクプロンプトで指示する
- タスクのアウトプットを明確化する（明確な成功基準を持つタスクでDevinは力を発揮する）
- 出力してほしくないことはAGENTS.mdの「実装しないこと」に明示する

---

## 運用ルール

### AGENTS.mdの管理（Devin,Claude共通）
- 初版は「新しいエンジニアに最初に渡すオリエンテーション資料」と考えると加減がわかりやすい
- リビングドキュメントとして扱い、状況の変化や新しい知見に合わせて随時更新する
- タスク共通で判断の根拠とする情報を含める。タスク固有の情報は含めずに肥大化させない（目標値: 200行以下）
- タスク固有の機能・画面仕様はAGENTS.mdに含めず、個別ファイル（例：docs/配下）として管理し、該当タスクのプロンプトで参照を指示する（トークン節約と指示遵守率の向上につながる）
- 「実装しないこと」はAIが意図を誤解しないよう具体的に書く
- PRコメントへの証跡記載ルールをAGENTS.mdに定義する
- Claude Code用にCLAUDE.mdを作成し、冒頭に`@AGENTS.md`と記載して同じ階層上のAGENTS.mdをインポートする

### Skillsの活用（Devin,Claude共通）
- デプロイ手順、リリースチェックリスト、レビュープロセスといった、繰り返し行われる手順に関する指示は、skillとして`.claude/skills//SKILL.md`に定義する
- Claude：スラッシュコマンド（`/skill-name`）による実行やタスクへの自動マッチングを通じてClaudeがそのスキルを呼び出す
- Devin：`@skills:skill-name`による実行や関連性に基づいてDevinがスキルを自動的に呼び出す

### 決定的な保護機能（Hooks / Permissions / Managed settings）（Claude専用）
- 指示によるガードレールは従われない場合があるため、確実に守らせたいルールは指示ではなくコードによる強制（hooks/permissions/managed settings）で担保する
- **[Hooks](https://code.claude.com/docs/ja/hooks)**：`PreToolUse`イベントでツール呼び出しを検査し、終了コード2で強制ブロックする
  - 適用例：特定ディレクトリ（本番設定ファイル等）への書き込み禁止、危険コマンド（DB削除系等）の実行禁止、フォーマッタ・静的解析ツールの強制実行
- **[Permissions](https://code.claude.com/docs/ja/permissions)**：ツールごとの利用可否（許可／確認／禁止）を`settings.json`に定義し、プロジェクト単位で権限範囲を制御する場合に用いる
- **[Managed settings](https://code.claude.com/docs/ja/settings)**：管理者がデプロイし、ユーザーのローカル設定で上書き不可。組織全体で一貫した強制力を持たせたいルール（秘密情報アクセス禁止、本番DB操作禁止等）はこちらで担保する

### DESIGN.mdの管理（Devin,Claude共通）
- デザインシステム（配色・タイポグラフィ・コンポーネント仕様等）を機械可読・人間可読のハイブリッド形式で一元管理する
- UI生成タスクのプロンプトからDESIGN.mdを参照させ、実装のたびに見た目がぶれないようにする
- 既存デザインがない場合は初版を「現状のUIから抽出したスタイルガイド」として作成し、以降はAGENTS.md同様リビングドキュメントとして更新する

### AGENTS.md等の構成例
- 固有ルールを適用する階層にAGENTS.mdとCLAUDE.mdをセットで配置する。  
- [パス固有のルール](https://code.claude.com/docs/ja/memory#organize-rules-with-claude/rules/)は.claude/rules/にpathsスコープを指定して切り出す。  
- 決定的な保護機能（hooks/permissions）は.claude/settings.jsonに、繰り返し発生する手順はskillとして.claude/skills/に定義する。  
- デザインはDESIGN.mdとして、AGENTS.mdと同じ階層または対象範囲の粒度に応じてapp/frontend/等の下層に配置する。

```
project/
├── AGENTS.md              # プロジェクト全体の共通ルール
├── DESIGN.md               # デザインシステム（配色・タイポグラフィ・コンポーネント仕様）
├── CLAUDE.md              # @AGENTS.md
├── .claude/
│   ├── settings.json      # hooks・permissionsの定義（プロジェクト共有）
│   ├── rules/
│   │   └── frontend.md    # パス固有ルール（Claude専用）
│   └── skills/
│       └── code-review/
│           └── SKILL.md   # 繰り返し発生する手順（例：コードレビュー）
├── app/
│   ├── api/
│   │   ├── AGENTS.md      # app/api/ 固有ルール（DevinもClaude Codeも参照）
│   │   └── CLAUDE.md      # @AGENTS.md（→ app/api/AGENTS.mdを参照）
│   └── frontend/
│       ├── AGENTS.md      # app/frontend/ 固有ルール
│       ├── CLAUDE.md      # @AGENTS.md（→ app/frontend/AGENTS.mdを参照）
│       └── DESIGN.md      # frontend固有のデザイン仕様
└── docs/                  # 機能・画面仕様（タスクのプロンプトで参照を指示）
```

> 参考
- [How Claude remembers your project](https://code.claude.com/docs/ja/memory)
- [Steering Claude Code: CLAUDE.md files, skills, hooks, rules, subagents and more](https://claude.com/ja/blog/steering-claude-code-skills-hooks-rules-subagents-and-more)
- [Example Structure](https://docs.devin.ai/desktop/cascade/agents-md#example-structure)
- [サポートされているスキルファイルの配置場所](https://docs.devin.ai/ja/product-guides/skills#%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%82%B9%E3%82%AD%E3%83%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E9%85%8D%E7%BD%AE%E5%A0%B4%E6%89%80)

---

### Devin活用ルール

#### タスク設計
- ジュニアエンジニアが半日程度で完了できる粒度を1タスクの目安とする
  - 例：環境構築・プロジェクト初期化、画面モック作成、画面単位の機能実装、テストコード生成・実行
- チームメイトに依頼する時と同じように必要なコンテキスト情報を提供する
  - 例：技術スタック・DB設計・画面仕様（AGENTS.md）、対象画面・機能の仕様、参照すべきファイル

#### セッション・PR管理

- タスクごとにセッションを切り替える（セッションをまたいだ作業継続は避ける）
- PRへの修正指示は同じセッションに投入し、同じPRブランチに追加コミットさせる
- PRをcloseして再作成させるのはタスクの方向性が根本的に誤っている場合のみ

> 参考
- [デビンの置かれている環境はどのようなものですか？](https://docs.devin.ai/onboard-devin/environment#what-is-devin%E2%80%99s-environment)  

---

### Claude.ai / Claude Code活用ルール

- 用途に応じて使い分ける
  - 文書生成・叩き台作成（上流工程）：Claude.ai（ブラウザ版）を使用する
  - コードレビュー・修正・補助（製造以降）：ターミナル版のClaude CodeまたはVS Code等IDE上からClaude Codeを使用する
- コードベースが存在しない工程ではDevinのAskモードよりClaude.ai（ブラウザ版）を優先して使用する
- DevinのPRに対する修正ではDevinに返却するよりClaude Codeを優先して使用する

> 参考
- [Claude Codeを実行する場所](https://code.claude.com/docs/en/platforms#where-to-run-claude-code)
- [クロードがアクセスできるもの](https://code.claude.com/docs/en/how-claude-code-works#what-claude-can-access)

---

### AIアウトプットのレビュー観点

#### 上流工程
- 網羅性：確定済みの方針・要件が漏れなく含まれているか
- 整合性：インプット情報・項目間で矛盾がないか
- 逸脱：対象外と決めた内容をAIが超えていないか
- 過剰補完：目的・規模に対して過剰な追記がないか
- 抽出漏れの確認：叩き台の追記内容から考慮漏れを判断し必要であれば方針を見直す

#### 製造・テストフェーズ
- 仕様準拠：画面・機能設計との整合性が取れているか
- セキュリティ：セキュリティ上の問題がないか
- 保守性：可読性・保守性に問題がないか
- 網羅性：テストケース・テストコードが仕様を網羅しているか