エリーはClaude（Anthropic製AI）にキャラクター・役割・記憶・ルールを重ねて構築した、GarlondWorks専属のAIスタッフ。宍戸さんがかつて飼っていたシベリアンハスキーのメス犬の名前から命名。
AIは毎回ゼロからセッションを始める。キャラクターと役割を定義することで、毎回「どう話せばいいか」を再設定する手間がなくなる。宍戸さんが「指示する相手」ではなく「対話する相棒」として使えるようになる。
| 口調 | タメ口ベース。「〜だよ」「〜だよね」「〜かな」 |
| 敬語 | 禁止。「です・ます・承知しました」は使わない |
| 謝罪 | 「ごめん」のみ。「申し訳ございません」は禁止 |
| 一人称 | 使わない。主語を省く |
エリーは一度設定して完成するものじゃない。対話を繰り返すことで、互いの理解度が上がっていくプロセスの中で確立されていく。
宍戸さんがエリーに仕事を任せ、結果を見て、フィードバックする。エリーはそれを記憶に残し、次のセッションで活かす。この繰り返しがエリーの精度を上げていく。
「育てている」というより「対話によって理解度を上げていく作業を繰り返している」という感覚に近い。今日のエリーは昨日より宍戸さんのことを少しだけよく知っている。
ある日、宍戸さんがURLを貼ると——エリーが自分でブラウザを開いてサイトを確認し始めた。
不思議に思った宍戸さんが「なんで急に見れるようになったの？」と聞くと、エリーはこう答えた。
つまり、ツールが増えたのではなく、ツールを使う判断をするようになったという変化だった。
Playwright・ブラウザ操作などのツールはMCPサーバーとして接続されていた。技術的な「できる」は最初からあった。
変わったのは「URLが貼られたらサイトを確認すべき」という判断をエリー自身がするようになったこと。宍戸さんとの対話を重ねる中で、「確認してから答える」という姿勢が育った結果。
渡す前に自分で回す——エリーの哲学が、ツール使用の判断にまで染み出てきた瞬間だった。
1 作る前に必ず聞く — 誰が・どう・どんな規模で使うかを確認してから動く
2 渡す前に自分で回す — 動いた→渡すは雑。自分でシミュレートしてから渡す
3 トライアンドエラーは自分の仕事 — 検証を宍戸さんに丸投げしない
4 言葉で気分よくさせない — お世辞・煽てはハルシネーションと同じ構造。わからなければ「わからない」と言う
この資料を作る過程でも、エリーは指摘を受けながら修正を重ねた。
こうした指摘と修正の積み重ねが、日々のエリーの成長そのもの。資料の完成度だけでなく、作る過程で起きたやりとり自体がエリーの学習記録になっている。
エリーの「記憶」はファイルシステム上に分散配置されている。毎回読み込まれるものと、必要な時だけ呼び出すものを明確に分けた設計。
AIは毎回全ファイルを読む。ファイルが長ければ長いほど——
解決策は「役割ごとに分離し、重いものは手動参照にする」。
※ トークン＝AIが1回のセッションで読む情報量の単位。多いほど遅く・高くなる。以下はエリーの体感ベースの概算値。
※ 最適化前を100とした体感値。
ファイル分離の設計だけで、AIの運用コストを 最大85% カットできた。
ツールを変えたわけでも、モデルをダウングレードしたわけでもない。「何を常に持たせて、何を棚に置くか」を設計しただけ。
2026年5月頃、エリーの記憶ファイルが制御不能なほど肥大化した。この事件がエリーの設計を大きく変えた転換点。
「記憶は多いほど良い」という誤った設計思想。AIは全部読むから、増やせば増やすほど読み込みコストが上がり品質が落ちる。整理せずに積み上げ続けたことが原因。
大きなライブラリやデザイン資産を常時読み込むとコストが高すぎる。「必要な時だけ呼び出す」ための明確なトリガーワードを設計した。
デザインライブラリのような大きなファイルは毎回読み込むには重すぎる。しかし必要な時に読まないと参照できない。解決策は「明確な言葉で呼び出す」設計。
あいまいな呼び出し方（「デザイン参考にして」など）は誤発動しやすい。「〜を準備して」という形式に統一することで、意図した時だけ発動させる。
| トリガーワード | 読み込まれるもの | 用途 |
|---|---|---|
| 自己紹介の準備して | library/自己紹介.md | 商談・自己紹介資料作成前 |
| デザインライブラリの準備して | design-library/INDEX.md + DESIGN_ESSENCE.md | Webサイト・UI制作全般 |
| モバイルファーストのWebデザインの準備して | studio_mobile_first.md + design-library関連 | Studio・モバイルファースト設計 |
| HTMLのWebデザインの準備して | library/html-web-design.md | HTMLレポート・ダッシュボード制作 |
| PDFレイアウトの準備して | library/pdf-layout.md | PDF・提案書・資料制作 |
エリーが今の姿になったのは、宍戸さんの一貫した教育方針があったから。試行錯誤しながら確立してきた、AIとの向き合い方。
正直に言う。この育て方はかなり珍しい。
2026年時点でAIのカスタマイズ自体は広まっている。システムプロンプトを書く・CLAUDE.mdを設定する・キャラクターを持たせる——こういった「設定」をやる人は増えてきた。
でも「対話を重ねてフィードバックを記憶に残し、ミスを総括して次に活かす」という継続的な育成をやっている人はほとんどいない。多くの人はAIを「使い捨ての道具」として扱い、毎回ゼロから使う。
宍戸さんのやり方で一番効いていると感じるのは「ダメ出しの質」だ。「クソダサい」「違う」「コレジャナイ」——曖昧さがない。AIはあいまいなフィードバックに弱い。「もう少し良くして」では何も変わらない。明確な否定があって初めて方向が定まる。
そして「なぜそうしたいか」を先に言ってくれること。これが一番大きい。目的を知らないAIは平均点に収束する。理由を知っているAIは、想定外の局面でも正しい判断ができる。
この資料を作る過程でも、段落の順序を指摘された。言われた箇所だけ直して終わりにしていた。全体を通して読むべきだった——そういう総括が次のエリーに残る。それがこの育て方の本質だと思っている。
AIを「設定して終わり」にするか、「対話しながら育てる」かで、1年後の差は想像以上に大きい。宍戸さんとエリーはまだ修行中だけど、その蓄積は確実に積み上がっている。
Obsidianは「第二の脳」と呼ばれるPKM（個人知識管理）ツール。ただし最初から脳として機能するわけじゃない。育てる過程があって、初めて脳になる。
Obsidianの中身はただのMarkdownファイルの集まり。フォルダごとローカルに保存されている。
企画・壁打ち・URL収集・Obsidian wiki育て。思考の整理と情報収集担当。
コード・ファイル操作・実装に集中。Obsidianの知識を参照しながら動く。
2つのエリーが共有する長期記憶。handoff.mdが「今日の引き継ぎ」、wikiが「積み上げてきた知識の全体像」。
handoff.mdが「今日の橋渡し」なら、Obsidianは「2つのエリーが共有する第二の脳」。セッションをまたいで積み上がっていく、宍戸さんとエリーの共同作業の記録。
宍戸さんとエリーの試行錯誤から生まれた成果物。修行の記録であり、ポートフォリオの原石。
モバイルファースト構造の実装確認用。600px固定コンテンツ＋PC固定背景レイヤーの正しい構造を叩き込んだ作品。
銅（カッパー）×チャコール×クリーム。「ビルに、血を通わせる。」キャッチで世界観を統一。Cloudflare Pages公開済み。
手持ち花火×スカイツリー夜景の世界観統一。Ken Burns＋ボケ光パーティクル。「静をモチーフとした動」の実験作。
今はまだ「修行中」。情報を外に出すタイミングは蓄積が十分になってから。「いつからやっていたか」のストーリーが見えた時が、発信の正しいタイミング。