Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
AI時代のTerminal環境を UNIX哲学で設計・運用する
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
yasunori
October 22, 2026
Programming
110
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AI時代のTerminal環境を UNIX哲学で設計・運用する
https://kichijojipm.connpass.com/event/404746/
yasunori
October 22, 2026
More Decks by yasunori
See All by yasunori
Server-Side Kotlin LT大会 vol.18 [Kotlin-lspの最新情報と Neovimのlsp設定例]
yasunori0418
1
930
Tried writing it vim9script
yasunori0418
0
69
ゴリラ.vim #36 ~ Vim x SNS ~ スポンサーセッション
yasunori0418
1
3.1k
Other Decks in Programming
See All in Programming
ハーネス設計入門 〜 基礎知識の整理から実務へのステップアップ 〜
kinopeee
28
34k
ActionController meets Protocol Buffers
sorah
0
630
dotNET_vulnclicker_intro.pdf
deka_morita
0
150
Next.js: The final boss of Web Performance
guaca
0
290
Compiling a real-world CLI tool to native with Static Hermes
tmikov2023
0
130
PumaからFalconに移行したRailsアプリケーションでの実践
falcon8823
0
190
【加筆修正版】Laravel のアプリケーションをどこにデプロイするか #phpcon_ehime
akase244
0
150
オーケストレーション記述言語 Katari
yukikurage
0
130
コーディング自動化の次へ。人の介入をゼロにするファクトリーとサポートAIによる実践
timakin
5
4.2k
Unity6 URPによる海底をテーマにしたVJシステムの解説 | Unity Shader 完全に理解した 勉強会
gam0022
0
370
GemmaをJevのように使ってみる / Use Gemma like Jev
kishida
5
810
エージェントを使い続けるためのメタワーク / Meta-work for keeping using the agent
rkaga
1
720
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
203
77k
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
320
The agentic SEO stack - context over prompts
schlessera
0
970
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.3k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
940
Discover your Explorer Soul
emna__ayadi
2
1.3k
Building Applications with DynamoDB
mza
96
7.2k
The SEO identity crisis: Don't let AI make you average
varn
0
590
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
220
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
640
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
630
Game over? The fight for quality and originality in the time of robots
wayneb77
1
310
Transcript
Terminal Night 3 AI時代のTerminal環境を UNIX哲学で設計‧運⽤する 2026年10⽉15⽇ 株式会社ログラス 1
⾃⼰紹介
会社紹介 3
None
None
None
None
None
None
None
None
ここから本編 12
今回のお品書き AI時代 UNIX哲学 実践 AIに環境を任せて起きた課題 「⼀つのことをうまくやる」を 責務として捉える 責務‧因果∕接続∕交換∕運⽤ の4つで⾒る
AI時代 14
AIによって環境を「作る」速度が上がった • 設定を書く AI Terminal 環境 • ツールを組み合わせる • 問題を調べて修正する
• 運⽤スクリプトまで作る 「作れる」≠「運⽤できる」
AIに任せるほど、複雑さも増やせる 責務が増える 依存が増える 因果関係が分からない ⼀つのツールが 複数の問題を解決し始める Aを使うためにB、 BのためにC…… 変更の影響が 予期しない別の場所に現れる
便利さの総量だけでは、良い環境か判断できない。
AIが直すほど、⼈間が理解できなくなる 理解負債が溜まる 認知負荷が上がる 問題が⾒えなくなる 動くのに、なぜ動くか 説明できない設定が増える 変更の量と速度に、 ⼈間の把握が追いつかない 責務を越えた改善が 症状を消して原因を隠す例:
PATH重複だけ消す 「直ったように⾒える」ことと「原因が分かった」ことは別。
便利ツールが本来の責務を越えるとき やってしまいそうな振る舞い ⾃分の環境での扱い • 依存ツールを独⾃に取得する • パッケージはNixに集約、⾃動更新は⽌める • AIの設定ファイルを⾃動で書き換える •
書き込まれたhookもNix側の定義へ移す → 管理元が⼆重になり、出所が追えない → 設定の正本はNixに⼀つ 管理元は⼀つに
AIに任せた失敗例: AIの確認ダイアログが、全部素通りしていた 起きたこと 引いた境界 • hook管理ツールが権限要求にも応答 • hook管理ツールを外しNixから直接登録 • 空設定でも「許可」を返していた
• 権限の判断はask‧permission-gateだけ → askの確認が全て素通りしていた → 1つの判断は1か所が担う 境界は知らない内に消える
AIに任せた失敗例: 書いたMCP設定が、⼀度も効いていなかった 起きたこと 引いた境界 • settings.jsonにMCPサーバーを定義 • 定義はmcp-servers.jsonへ分離 • Claude
Codeはそこを読まない • 登録はclaude mcp addに委ねる → textlint‧tirithは⼀度も起動せず → 読む側の仕様に合わせて置く 書いた ≠ 効いている
UNIX哲学 21
UNIX哲学をもう⼀度考える 「⼀つのことを上⼿くやる」 では、「機能が⼀つ」ならよいのか?
機能数ではなく「責務」を⾒る 悪い⾒⽅ ⾒るべきもの 機能が多い / 少ない 依存している / していない その機能は同じ責務に向いているか
責務の境界を越えていないか 「何をするか」より「何のためにするか」
「一つの責務を上手く遂行する。」
Neovimは機能が多い。それでも責務は明確 テキスト編集 Neovim 検索 補完 LSP 複数の機能があっても、同じ責務に向いていればよい。 拡張
「利⽤」と「統治」は違う 利⽤:なくても他は動く 統治:ないと他が動かない • NeovimからGit‧Terminalを使う • Neovimが壊れるとGit操作も⽌まる • worktreeはworktrunk、sessionはherdr •
worktree‧sessionまでNeovimが抱える → 使うが、任せきらない → 責務が絡み合う 利⽤ ≠ 統治
責務を局所化すると、因果関係も局所化する 責務の局所化 因果関係の 局所化 原因を追いやすい 副作⽤が悪いのではない。どの責務で起きたか説明できることが重要
実践 28
汎⽤インターフェースが境界をつなぐ Input 標準‧慣習 ツール Output 標準‧慣習 FHS / XDG /
UNIXの標準⼊出⼒ / ファイル / ソケット など 単独で完結させず、境界を保ったまま接続する
交換可能性を残す A 汎⽤ インターフェース 交換できる ≠ 実際に交換する B
責務ごとに分けた⾃分のTerminal環境 Ghostty 端末を表⽰する zsh コマンドを解釈する herdr シェルのセッションを管理する Neovim テキストを編集する Git
変更履歴を管理する Nix パッケージを管理する AI Agent 環境を操作する主体
説明できる環境は、認知負荷が低い 原因探索 変更 検証 復旧 影響範囲を絞れる 変更箇所を限定できる 何を確認すべきか明確 戻す対象が分かる 責務の境界は、運⽤のための境界でもある。
AIに任せる範囲を⼈間が決める Human deny ask hook AI Agent AIの能⼒を制限するのではなく、AIが触れる責務を定義する 例: sudo‧秘密情報はdeny、push‧rmは確認、rebaseは計画承認後
Small Tools
運⽤は⼩さく回す Observe Problem Small Change Verify Operate ⼤きな⾃動化で⼀気に変えるのではなく、因果関係を追える単位で改善する
この考え⽅で⽬指すTerminal環境 責務‧因果 接続 交換 運⽤ それぞれが何を担当す るか明確 汎⽤インターフェース で組み合わせ可能か 必要なら別の実装へ移
れる 原因と影響を追える 変更の影響を追えるか 「便利か」だけではなく、「理解できる構造か」を⾒る。
AIは何でもできる。 だからこそ、 ⼈間が何をさせるかを決める。
None