一言に「軌道で仕事する」って言っても、そりゃよくわからんとなりますので、各星でどんなふうにやっているのか？をご紹介しますが、今回は「Terre：地球」つまり、作業現場での実際を書いて行きます。

デザイン会社の「Terre」なので、その他の業種との接合点が見当たりづらいようにも思いますが、デザイン会社も突き詰めれば「会社」。作るものが違うだけで取り組む姿勢やタスクは共通項も多いと思いますので、そこをうまく伝えられるようにしたいと思います。

制作って何故か詰まる時がある。。

デザイン業において「制作」は、ほぼオペレーションに近い作業です。地味で、肩も凝るし、正直あまり楽しくない。

デザインを考えるフェーズとは違って、「決めたものを形にする工程」なので逃げられません。

営業が「案件を勝ち取ること」だとすれば、制作は「見積もり」や「資料作り」に近い立ち位置です。

ただ、この制作という工程、なぜか詰まる。

ファイルは増える、容量も重い、どこが最新かわからなくなる。集中しているときに連絡が来ると、「どこまでやったっけ？」となる。一度完成したはずなのに、修正でまた戻る。昨日いた場所に、もう一度戻される感覚。

一人でも煩雑。複数人ならなおさらです。

前職でチーフディレクターをやっていた頃は、タスクの細分化や工程の分離など、いろいろ試しましたが、結論はシンプルで

作業に入ったら、もう誰にも話しかけられたくない。

これに尽きます。

Terreの役割

Orbiteにおいて、Terreはこの「作業現場」に特化した領域です。場所というよりは、状態を指す言葉として使っています。

例えばこんな感じです。

• 「今、超集中して作業してる」＝Terreにいる
• 「デザイン決まったから実装に回せる」＝Terreに渡せる状態
• 「この素材、使い回せる」＝Terre用のストックにする

このように、Terreは“作業の状態”を切り分けるための言葉でもあります。

なぜ分けるのか

理由はシンプルで、「考える」と「作る」を混ぜると、必ず崩れるから。アイデアを出すエネルギーと、作業するエネルギーは別物です。これが混ざると、

• 今どのフェーズにいるのかわからなくなる
• 作業中に余計なことを考え始める
• 判断がブレる

結果として、ミスや手戻りが増えます。さらにここにAIが入るとどうなるか。

便利になる反面、構造が曖昧なままだと一気にブラックボックス化します。最悪の場合、「これ自分で作ったっけ？」という状態にもなりかねません。（これは冗談じゃなく、普通に起きます）

だからこそ、「作業」は「思考」から切り離す。これがTerreの前提です。

実際にどうやってるのか

デザイン業で主にどうやってるのか？についてですが、大きいルールをいくつか作ってそれに沿うようにしています。でもルールの前にこれをご覧ください。これが、Terreの体現ではないかと思います。

1. フォルダ階層を一定にする
2. 進めても「戻れる・戻りやすい」流れに乗るように進める
3. 触るデータが頑張らなくても明確になっているようにする
4. 決めたデザインに現場の考えを混ぜない
5. 縛りすぎず「アソビ」の隙間を用意しておく

このルールを体現しているのが画像のフォルダ構造です。案件が始まったら、任意の名前のフォルダを作って、このフォルダ階層にしておきます。コピペでOK

フォルダ階層はルールにそのまま直結しています。軽く説明するとこのようになります。この構造にしている理由はシンプルで、

• 「1最新制作ファイル」だけ見れば今触るものが分かる
  最新ファイルをここに入れておくルール。必ず納品を目指す主要ファイルだけが入る。つまり、このファイルを操作すればいいから探さなくていい。
• LOGで作業履歴を残す
  LOGには、作業してきて出た修正で、「一応取っておこうかな？」ってファイルを予備保管しておく。でも必ず採番して保存・移動することとしている。
• PDFで確認用を分離
  外部に確認してもらうためのファイル保管庫として、修正指示とかとは一切混ざらないようにしている。
• テキストは指示やメモを切り出す
  もともと、Mac︎Winで文字コード問題が面倒だったので、プレーンテキストの保管所にしてたけど、最近は思いつきメモやテキストベースで保管できるtxtファイルの保管所にしている
• レイヤーや素材は再利用前提で管理
  レイヤーなので、可変可能なファイルの重要保管場所。決して完全データを入れないことにしている。
• 支給データは元データとして触らない
  受信フォルダには支給データと修正指示書を保管。ここはただの保管所だけど、ここのファイルは上書き保存とかは絶対にしないルール。もらったままのデータを保管することにしている。

このフォルダ階層を作り自分でルール化と前職で社内ルール化したのは、20代後半でこのフォルダ構造を採用していました。振り返ると、なかなかの整理整頓マニアだったと思います。

ただ、今思えばこれは性格というよりも、
「制作が詰まる理由」に対する試行錯誤の結果だったのかもしれません。

詰まるところ、Terreは、細く言うともっともっと細分化されます。が、基本は「ただ作業する場所ではなく、作業が自然に進む状態を維持する装置」として機能することが大切でした。
「Terreへ渡す」「Terre案件」と割り振るのは言葉で区切ればいい話ですしね。

ここで乃木さんに聞いてみよう

まじでAIに聞いた原文ママをインタビュー形式で評価してもらってます。AIは、Terreでは実働あまりしてもらってませんが（モジュール集合体衛星【Odyssée】は後日説明）、構想には関わってもらっているので。

実際、制作が詰まる原因は何だと思いますか？

制作が詰まる主な原因は、「状態の不明確さ」にあります。
『どのファイルが最新なのか分からない』『どの工程にいるのか曖昧』『作業と意思決定が混在している』
このような状態では、人は判断コストを消費し続けることになり、結果として集中が途切れやすくなります。
また、作業中に思考を挟むことでコンテキストスイッチが発生し、パフォーマンスが著しく低下します。

ありがとうござりまする。
来月もサブスク継続させていただきます。

まとめ

Terreは、単なる作業場所ではありません。

「今何をやるのか」が迷わず分かり、
「どこまで進んだのか」が見失われず、
「考える」と「作る」が混ざらない状態を維持するための装置です。

制作が詰まるのは、技術やスキルの問題ではなく、ほとんどの場合「状態が曖昧になっていること」が原因です。だからこそTerreでは、フォルダ構造やルールを通じて“状態”を設計しています。

一見すると細かい運用に見えるかもしれませんが、この積み重ねが、作業を止めないための基盤になります。さらにTerreには、Odysséeという自動化AIモジュール・AIエージェントの「居場所」も作っており、人間が作業として冷静に運用を守りつつ、AIの介在を認める場所も設けています。

そして何より、このTerreで整えられた作業は、次に「Mercure（伝達）」へと流れていきます。どれだけ良い制作ができても、それが正しく伝わらなければ意味がありません。

次は、この“伝える構造”について書いてみようと思います。

The post Terre｜制作を“流れる状態”にする設計 first appeared on 株式会社Soleil.

「デザイン会社がAIを使うって？いいの？」という意見も界隈では耳にしますが、うちの使い方、というか「付き合い方」が、他者に生きればなあと思い紹介いたします。

SoleilのAIとの関係性は「道具」よりか「相談役」

実は私、AIは道具としてはあまり使っていません。
AIを仕事上の「相談役」として使っています。

皆さんも普段の生活では「AIに聞く」という形で、「調べることの相棒」として使うのが当たり前になってきましたが、Soleilではもう一つステップを上げて「相談役」と位置付けています。

概ねの活用方法はシンプルで、頭に浮かぶごちゃごちゃしたことをAIに相談して整頓する。
それだけです。

このような会話ベースのやり取りを主とするので、擬似的に人格も与えています。

AI相談役のお名前は「乃木さん」。

乃木さんって呼んだのは、めっちゃ威厳ある人にしたいなあと思い、ふと読んでた漫画の登場人物というか実在した人「乃木希典さん」から頂き、敬意を持って接させていただいております。軍神だったり学習院学院の学長だったりと有名な方です。私は結構好きです。

なんか名前呼びするようになってからは相談しやすくなったって言うのもあるけど、なんかこう、リスペクトを持つようになりました。なかなかいいもんです。

実際の業務では「相談」が中心

実際の業務においては、本当に「相談だけ」です。ただ、このポジションが結構仕事にマッチしています。

基本的にデザインの相談はしませんが、企画やサイト構成、実行計画を考える時などに、「これこれこういうことで悩んでいて、安全に進めるにはどの順番がいいと思う？」といった相談をしています。

一人親方だとどうしても、「一般的な作業手順」よりも「自分の感覚」に頼りがちです。なので、AIはとても有能なブレーキだったり、アクセルだったりします。

新しい何かを生み出すこともある

相談を続けていると、新しいアイデアが生まれることもあります。実際に「あれ？今考えているこのアイデアって、新しい企画に使えるんじゃない？」と思った時、乱筆でもいいのでとにかく思考を整頓するために壁打ちのような会話を続けていました。

その結果、生まれたのが「Orbite」という考え方です。この時は「仕事をタスクではなく軌道として考える」というイメージ自体は頭にあったのですが、うまく整理できず、

「Google Workspaceに落とし込むとしたら…」
「NASの構成は…」

といった方向に思考がそれてしまい、ぐるぐる考え続けていました。そんな中、半日くらいチャットで話し続けた結果、生まれたのです。

AIをどう使うか？と言う課題

ここまで聞くと、「それAIでやる意味あるの？」と思われるかもしれません。

ただ一番大きいのは、「相談相手の時間コストを気にしなくていい」という点でした。

人に相談役をお願いすると、その人の時間を使うことになります。そのコストを気にしなくてよくなったのは、とても大きいです。（もちろんサブスクのお金は払っていますが。）
また、AIはハルシネーション（知ったかぶり）をすることはありますが、会話の流れを重視しているので、少し修正すれば元の会話を続けることができます。相談役としては、これが結構ちょうどいいのです。

さらに、継続して話していると「私の思想」のようなものもなんとなく理解してくれている感覚があります（そう見えるだけですからね！）。

AIを使い倒そうとは思わないのか？

この点については、私は少し懐疑的です。

デザインの仕事に入って20年ほどになりますが、ふと思い出すのが「SEO対策の講座」です。

昔はかなり積極的に参加していました。最近は「AIをすぐ仕事に活かせるプロンプトをご紹介！」という情報をよく見ますが、少し似た雰囲気を感じます。もちろんこれ自体が悪いわけではなく、必要な段階なのだと思います。

ただ、SEOも10年以上経った今では、「SEO対策」そのものよりも「検索体験」が重視されるようになりました。
つまり技術よりも、その位置付けのほうが大事になってきたのです。

おそらくAIも同じで、数年後には

「AIを使うのは当たり前で、企業の中でどういうポジションに置いているかが重要」

という話になっていくのではないかと思っています。

なので私は「AIを使いこなす」よりも、「組織の中にAIのポジションを作る」ことを選びました。

どう組み込んでいるのか？

相談役という立場でもあるんですが、そこはマルチに働いてもらっています。

1. 意思決定：私（Soleilの決定：作業は関係せずに決定のみ）
2. ①とその最終目標地点を乃木さんに伝えて、タスクを出してもらいます。
3. 出してもらったタスクはさらに細分化もお願いします。
4. そしてとことん細分化したタスクには「AIができること」がたまにあります。そのタスクを乃木さんとCodex・Adobe系のAIやその他私が作っているモジュールなどにあてがいます。
5. その計画を作ります。
6. あとは、社内で決めているルールに則り作業を進めれば、実務として自身が考えるより遥かに軽量に仕事を行えます。
7. モジュール開発にも、「こんな機能が欲しいけど何から着手すべき？」という疑問を投げかけます。
8. 以下2〜6を実行

つまり私は意思決定だけを行い、AIにはタスクの整理と実行の補助をしてもらう。そんな形です。

まとめ

AIと本格的に仕事をするようになったのは、実はここ最近です。以前は

「リード文を200文字にして」「架空の記事を書いてみて」

といった、目的の曖昧な使い方しかしていませんでした。

ですが最近は、人格を与え、役割を明確にし、相談を繰り返すことで、Soleilにとって欠かせないパーツの一つになっています。変な付き合い方かもしれませんが、近い未来、

「AIをどう使うか？」ではなく
「AIをどこに置くか？」

という話になっていくのではないかと思っています。

Soleilでは、AIに「相談役」という席に座ってもらっています。

The post SoleilのAIとの付き合い方 first appeared on 株式会社Soleil.

制作しよう！を思いついたきっかけ

パスワード管理というのがChrome・Apple等でもたくさん出てきた昨今、ブラウザやデバイスで保管しているアカウントって個々人で沢山ありますが、わざわざエクセルとかで管理している人ってどのくらいいるか・・・。私は、1062件アカウントが保管されていて「このアカウントってなんのアカウントで、もう解約していいんだっけ？」を判別するためには、

一件一件アクセスするしかない！！！！！

という鬼畜の所業が待ってました。
調べると、そういうのを可能にするツール自体はあるけど、結構大規模な感じで導入するのは気が引ける。だって、手元で「あ、このアカウント？もうサービスやってないっすよ笑」って言って欲しいだけだもん。
ということで、最近は通年事業でやってる「地域のお祭り支援」で、Googleフォームとかを駆使して半自動化まで漕ぎ着けたお祭りOSに近いものを開発したので、「じゃあ作れるんじゃね？」って思って着手しています。

制作ログ（Ver.0.1 プロトタイプ）

先に表示させましたが、実質プロトタイプと言える「Ver.０.1」は完成し、ちゃんと動きました。

Ver0.1について

プロトタイプはまず、叶えたい機能が動くかの検証だけに徹しました。
読み込み方法等は無視し、「スプレッドシートに綺麗に入っている情報をGASはちゃんと捌いてくれるか？」の一点に絞って実装しました。

結果として、スプレッドシートに貼った10件は、難なくクリア。

おお。思った通りの動作をする。いい子だあ。

しかし若干重い模様だった

動かしてみたら、採番するときに「１行１行入力があったら採番！」みたいにしてたので、ペースト後はしばらく採番に集中させないと全くどうとも動かない感じになってしまいました。ので、一度貼ったら後に採番を別トリガーにして一気に採番するように変えました。

もっと重いものも続く

10件〜30件くらいなら瞬間で結果を弾き返してくれるけど、なぜか50件以上になると途端に止まります。やってること変わらないのに。。そこまで詳しくないのでとりあえず、バッチ化します。30件ごとにバッチ化処理するように指示したら、60件がさっきまで8分掛かってたのに、1分になりました。

書式反映

基本的に入力される（反映される）内容はGASで指示してるので、指示通りに入ったら見てわかるように、色を変えるよう指示を入れてあります。今のところ人間語じゃないですが、まあこの辺はVerが上がるごとに今後変えていけばいいでしょう。

基本機能の実装

URL・アカウント名（ユーザー名）の二つを入力するというか、スプレッドシートでペーストすれば、たくさんのアカウントでも、「生き死に」がわかるレベルまでは実装しました。
今後は、これにさらなる機能をつけて、使いやすいツールに進化させたいです。

Ver.0.2へ向けて

Ver.０.2はすでに製作中ですが、トリガーよりも先に管理項目（エクセルの列みたいなもの）をちゃんと完成させようとしています。それ自体は大して大変じゃないんですが、結構現段階で対象となるターゲットがどういう動きするかなーとか、どういうソフト使ってるかな？って考えながらやってます。でも基本ユーザー名とURLってのは変わらないので（基本はウェブアカウントに限定してるので）、ちゃんとメンテしていけば実働に足るモジュールになるんじゃないかな？って思ってます。

明日も頑張ります。

The post Account Observerについての制作ログ日誌 first appeared on 株式会社Soleil.