デザイン制作をしていると、WordPressサイトの修正って「ちょっと直すだけ」のつもりが、なぜか大きくなっていくことがあります。話の始まりはいつも些細で、「ちょっとした追加」だったはずなのに、実装段階で表示が崩れる、動きがおかしい。気づけば「これ、どこから触ればいいんだ？」という状態になる。今回のボディメイクジムのサイト修繕も、まさにそこから始まりました。

きっかけはシンプルで、「新規店舗を開業するので、そのページを作ってほしい」という依頼です。

ただ実際に触り始めてみると、単純にページを追加するよりも、構造自体を整えた方が、今後お店側で更新していく上でも扱いやすくなると判断しました。結果として、部分修正ではなく、いわゆる“基礎工事”に近い対応となり、サイト全体のメジャーアップデートへと発展していきます。

作業自体はそれなりに大変でしたが、AIやエージェントの協力もあり、振り返ってみるとかなり汎用性のある作業プロセスになりました。自作テーマからの見直しや、構造の整理を考えている方にとっては、進め方のヒントになる部分もあると思います。今回はその一連の流れを、いくつかの工程に分けてご紹介していきます。

話のきっかけとご紹介

個人的な知り合いというか、後輩がやっているボディメイクサロンにかかわるデザイン制作物をいろいろと作っており、ウェブサイトもリニューアルやサポートなどを継続して行っています。当初は1店舗のみだったのが、うれしいことに事業が好調なようで、店舗を増やすこととなったそうで、今回の相談にいたりました。相談の際にもらった希望は「店舗が増えるので店舗を紹介するページが欲しい」でした。

実はよくある案件定義ですよね。ちょっとした改定と思いがちですが、「初めて店舗を増やす」ということは、おそらく今後に店舗を増やしていくよりよっぽど重要な一歩目です。店舗としての大変さもですが、看板としてのウェブサイトも、そのくらいの本腰を入れてメジャーアップデートをした方が、お店のためにも運営を手伝っているSoleilとしても、増えてからではなく、増えることを想定してアップデートに備えていこう。とおもいました。そこが大きなきっかけです。

浮き出てきた問題

ここで一つ、制作会社あるあるかもしれません。

「オリジナルテーマは、拡張を前提に作られていないことが多い」

制作は基本的に「納品」がゴールになるため、要件を満たすことが優先され、将来的な拡張や運用まで考慮されていないケースも少なくありません。

私自身も例外ではなく、当初は「店舗が増える」ことを想定していなかったため、「修正があればその都度対応すればいい」という設計で作っていました。

しかし今回の相談をきっかけに、

• 店舗の増加
• 店舗ごとの情報出し分け
• SEOやMEOの対応
• スタッフやFAQの管理

など、今後必要になりそうな要素が一気に見えてきました。

要望・要件の整理

要望をあえて問題として浮き彫りにすることで

「単純に修正するだけではない方がいいんじゃない？思い切ってメジャーアップデートしちゃおう！」

と思いました。今回の想定で行けば、スタッフがめっちゃ増えても、店舗が全国展開しても、UI（ユーザーインターフェース）を改善していくだけで対応できるはず（大きく言いすぎかも笑）。それであれば、テーマ自体を現段階で骨格を作り直して増える想定の骨格にしておけば、スマートでしなやかなつくりになるはずです。ボディーメイクジムのサイトなので、プログラムもダイエットすることにします。

テーマの標準化について（標準化って？その特性）

テーマの標準化というと、いわゆる「汎用化（使い回し）」をイメージしがちですが、今回のそれは少しニュアンスが違います。どちらかというと、「運用しながら育てていける構造に整える」ための標準化に近い考え方です。

最初から完璧な形を作るのではなく、後から拡張しても崩れない状態を作る。

そのために、今回は以下の3つを軸に設計しました。

• 役割を分ける
  何度も使う情報は「情報カード」として切り出し、カスタム投稿として管理します。どの情報をカード化するかを整理することで、再利用性と拡張性を確保します。
• 構造を整理する
  情報カードを運用するための土台として、テーマのファイル構造を見直し、親テーマとして成立する形に再構築しました。また、mu-pluginsを用いて機能を分離し、システムの軽量化と運用のしやすさを両立しています。
• 迷わないルールを作る
  カスタム投稿やフィールドが増えると運用が複雑になりがちですが、「選択するだけ」で扱えるように設計することで、迷いを減らしています。mu-plugins、ACF、テーマ側のPHPを役割ごとに整理することで、クライアントが無理なく運用できる状態を目指しました。

このように、「作るためのテーマ」ではなく、「運用できるテーマ」にすることを前提に標準化を進めました。

次回へのまとめ

今回の記事は初回ですが、主に標準化をするにあたっての構想内容をご紹介しました。「標準化へ変える」というよりかは「作ったものを新たな要望に合わせて整える」ための準備段階です。

大事なことは「構想を最初に作りすぎず明文化だけしておいて、いっちばんちっこい機能からつくる」ことを大事に進めています。次回は「いちばんちっこい機能」となる情報のカード化と、ベースになる親テーマ（でけえやん）の構築についてお話ししますが、いよいよAIとの共同作業が実現した回になります。

ちょっとだけ次回予告ですが、基本的な設計思想（一番大事）ができた後にやることは一つAIとの連携作業です。

1. ローカルのテストサイトをターミナルで監視＆現状をAIに報告
2. 監視対象を操作するように、AIアシスタントとAIエージェントに指示して、ファイルが出来上がるのを待つ
3. 私は仕上がりチェックをする

という流れの説明がほとんどになるはず、、。

実際のところ、結構数人のオペレーターがいるレベルの作業量を短時間でこなせたので、ご興味のある方は是非お楽しみに！

The post 【はじまり】WordPressサイトメジャーアップデートした話① first appeared on 株式会社Soleil.

以前紹介した「Orbite」という仕事の考え方について、もう少し入り込んだ説明をしたいと思います。

一言に「軌道で仕事する」って言っても、そりゃよくわからんとなりますので、各星でどんなふうにやっているのか？をご紹介しますが、今回は「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.

前回の記事から３ヶ月も経ってしまいましたが、刈った草を処理するタイミングがやってまいりました。

さて前回から少し畑の状況も、家族と整理しているうちに色々とはっきりしたこともあるのでそこも含めて書いていきたいと思います。

最終的には妻方の実家で義父と義母が自宅から近い農園を持つことが第一目標で、うまく進められるようであれば、レンタル農地のような活用もできればいいなあと考えている状況です。

現状の条件整理

最終的な目標としてはレンタル農地ではありますが、まずは畑として動かせるように整地し直すのが目下の目標です。そのため、草を刈ってから新たにわかったことも整理します。
現状の問題として見えている所は以下のとおりです。

と、こんなところですが、大きい問題の方を義父に詳しく聞き、対策を練ることにしました。

聞いた内容をまとめると大きめの問題がはっきりしました。畑の場所はかつては「水田」だったそうです。また、近隣に沢があり、それを塞ぐように道路ができて現在の土地形状になったとのことです。

昔の話からの推察（大きめの問題）

今回も3連休のうち1日しか従事できなかったのですが、、。話を詳しく聞けたので対策が練れます。つまり大きめの問題に関してはこのような解決になるかと思います。

大きめの問題点	原因・課題	考えている解決策
草がやばいくらい 生えている	草刈り。木は余裕があれば移動。	頑張る。あと0.1ヘクタール
まとまった雨が降ると 3日ほど水が抜けない	おそらく50cmくらい掘ると粘土層が出るんでは？ 水が3日くらい抜けないのは水田で長く使ってたせい？ （かれこれ30年以上前らしいが）	草刈りで土が出たら、名渠排水（土の上に排水路）で 排水できるようにする。 畑の周囲に埋もれつつある水路を 復活させる。
拳大の大きさを超える石が そこそこある	機械を通せない（怖くて）。 なんとか浮かして畑として 使わないエリア（奥の方）に集めたい。	草刈りが終わったら目立つ石をのかして、 思い切って10〜20cm機械を通す。 その後細かい石を避ける。

解決策は義父と相談したりして決めたけど、順番も気にしないといけない感じです。排水をまずは重点的に改善しつつ、草を処理していくのがいいのかな？と思っています。流れとしては草刈りと水路確保を並行して行い、雨天時に排水がちゃんとされることを確認しつつ、耕して石をどかしていく感じですね。

小さい問題の方

こちらは目につくけど解決策はかんたんな話です。

草に関しては、草マルチとして土に還す方法と、もう捨てちゃう方法をハイブリットしてやっていけばいいかな？と思っています。念の為、ジモティで「刈草要る人にお譲りします！」ってもやってるので、最悪なくってしまって草マルチに使えなくても問題はありませんし、余った刈草は環境センターへ持ち込めばOKと、農地のある自治体に聞いて確認済みです。
一番やっちゃいけないのは「野焼き」ですので、それだけはここでやらない宣言をしておきます。

水路の埋まりは1本ずつ解決しますが、ゴミのポイ捨てもあるので（けしからん）蓋をするのかどうするのか？は予算との相談で考えていきますが、掃除して流れる確認を取るのが最優先です。

従事者が遠方（私と妻）に関しては、もうどこかで覚悟を決めようと考えています。関係各所には事前にお伝えし、1ヶ月のみ本職拠点を畑まで通える実家に移し、梅雨前に作業を完了させるプランで考えています。家族からは了承は得ていますが、PCどうやって持っていこうかな

こんな感じで解決策は考えていますが、果たしてどうなることやら。まずは、刈っただけで放置している草をまとめて、次のステップへ進められるように環境を整えることとしました。

刈った草をどかします

草を12月に刈落とし、そのまま寝かせるしかなくはや3ヶ月。大きく変わった点としては、まずは草が軽くなりました！枯らすのが目的で放置していたから当然ですかね。でもできれば1〜2ヶ月で着手できればよかった
理由は暖かくなってきて元気に草が生えてきてしまっていました。。。遠方ということもあり、畑への訪問が3月に入り込んでしまいました。

なので今回は主に草の処理に加えて、新たな草を刈るところを重点的に行いました。

今回も主な作業要員は義父の指導のもと私。妻は親戚キッズたちをトランポリンに連れていくという重労働を担ってくれています。大人になってからの小学生とのトランポリンは農業を凌ぐ重労働です。

さて実際の作業ですが、以下のとおりの単純作業です。単純なだけに鬼苦しい作業となります。鬼苦しくて撮影がほとんどできませんでした。。。。。

1. 義父が刈る
2. 少し後ろから私がレーキで刈った草をまとめて山を作る
3. まとめた山をさらに、一ヶ所の大きな山を作ってフォークで運ぶ
4. 以下繰り返し（10時開始16時終了）

が今日の主な作業です。

重労働から帰ってきたみんなが合流

昼過ぎくらいまで作業を続けたのちに、遊びに行っていた妻たちが合流してくれました
義父とはむしろ仲がいいくらいなのですが、草刈りのエンジン音と黙々と刈草を運ぶだけの私の二人だけでは会話など生んでる隙もありませんでしたが、子供達が合流してくれたことで、場が明るくなります笑。少し余裕ができて撮影もできました。前回同様、周辺が住宅街なので、ぼかしをご理解ください。

どんどんと作業が進み、ものすごい量の刈草が溜まりました！でもこれで実はまだ半分くらい
しかしこの時点でもう夕方の16時に。これ以上は私の体が危険信号をあげていたので、作業終了。。。

今回の成果

乾燥させて軽くするために放置していた刈草をごっそりと集めることができました。そして作業の見通しと今後の時間的なスケジュールも立てられそうです。

次回の目標は今回の作業から概ねみえました、水路の確保と草刈りの続き、そしてせっかくならもう1ヶ月向こうに行ってしまえ！です。
幸い事前のお知らせと準備さえしておけば、作業拠点を会社から1ヶ月程度の期間限定で移動することは、通常業務的にも問題ございません。準備さえしておけば、、、。目標は5〜6月にかけての1ヶ月で、畑を復活させていきたいと思います！

The post 【開墾Re Boot】刈った草を処理まで持っていきます。 first appeared on 株式会社Soleil.

その2です。前回は公式LINEの設定まででした。公式LINEはルール内で最大限に生かすという前提でしたので、先に設定しました。この案件に関しては、「一般の方・参加者」と「事務局（私）」をある程度「自動化で繋ぐ」というのが主題でもあるので、特殊なツールや大規模なグループウェアのようなものは極力避けたかったのです。

というわけで、ここからは少し専門的ですが「技術的なログ」として書き留めていきたいと思います。

ある程度のファクトチェックはしておりますので、ひとつご参考までに参照いただければと思います。

今回構成を組み上げたツールについて。

誰もが知っていそうなツールで実現しました。意外と使えるツールでしたし、汎用性も高くカスタマイズも（頑張れば）スムーズにいきます。

この5個です。
特別なシステムを作ったわけではなく、誰でも知っているようなツールを組み合わせただけです。ただし、組み合わせ方を少し工夫すると、地域のお祭りでも意外としっかりした仕組みが作れるものです。

APIを組み込みデータのやり取りを実現

今回私が組み上げた最終的な仕組みの説明図をここに載せておきます。

ざっとですが説明しますと、オレンジ色が下に敷いてある部分を自動処理にしています。

途中に集積されるスプレッドシートは（意外とみなさん持っている）グーグルアカウントで共有することで、リアルタイムで閲覧できるようになり、尚且つシートフィールドの中に正確に入る情報なので、取扱項目さえ共有しておけば、パンフレットを作る人・応募者と連絡を取り合う人・説明会を取り仕切る人みんなが状況を把握できます。

また、窓口をLINEにしてグループ分けすることで複数人で管理ができ、定型文も設定して置けるので、イレギュラーなお問い合わせや込み入ったお話などを除くほとんどの問い合わせに、自動もしくは定型文で迷わず回答できます。

迷わずっていうのが重要ですね。迷って探すのは非常にエネルギーを使います。時代は省エネです。

上の図は概念図みたいなものなので、同系統の事業の自動化スキームにも利用できるかもしれません。

自動化くんことGoogle Apps Scriptはどう言うことをするの？

これは意外と簡単な命令しか出してなくて、

「指定したGoogleフォームの送信ボタンが押されたら、スプレッドシートへの保管以外に、お祭りサイトの〇〇というカスタム投稿に、必要な項目（名前・団体名・プロフィールなど）を送信しなさい」

と言う命令を入れただけです。

その代わり用意しなくちゃいけないのは、本サイト側に「各フォームに対応したカスタム投稿」と「列の情報を受け取るための受け皿となるカスタムフィールド」を作っておき、投稿スラッグ・フィールド名といったあらかじめ命名しておく必要のある「下拵え」が必須になります。

そこまで準備できたら、上記の命令をスプレッドシートの機能拡張にあるApps Scriptに命令プログラムを登録して、受け取りをチェックしたら完了です。

今、簡単に言っちゃいましたが、実はここの命令プログラムもWordPressのセキュリティもサーバーのセキュリティーもという、3人の頑固者を突破しなくてはなりません。この段階が一番時間がかかりました。。。

詳しい設計に関しては、お問合せください。

協賛者情報の登録について

協賛者情報には個人情報や企業情報が含まれるため、画面のビジュアル公開は控えていますが、こちらにもある程度の自動化を組み込んでいます。

実は機能的にはWordPress内で完結した仕組みなのですが。

毎年たくさんの協賛を地元の企業様・一般の方もいただいており、本当に感謝感謝です。ですが、これまでの管理方法はかなりアナログで、会計担当者が通帳の入金記録を見ながら「多分この会社さんかな…（去年の資料を参照）」という形で確認している状態でした。その為社名様が間違うことや、匿名でお願いしてたのに！なんて事故も今までにありました。なのでその反省を活かした設計を考えました。

もういっそのことマスター情報を作ってしまおう

と言うことで、外部でも構わないのですが、「一度でも協賛をしてくれた方」のリストというかDBを作ります。そのDBには社名や住所など事務局がご案内送付などの管理をするために必要な情報を保管してあります。これを協賛マスターとします。
そして管理用レコードとして、WordPress側には「協賛実績」という管理用のカスタム投稿を用意しておきます。実績を年度ごとに登録するのですが、登録する際にはそのDBのお名前（社名）のみを参照し、金額と年度を入力して保存。
保管する際には年度がタクソノミーとして、また同時にタイトルに自動で書き加えられて保管されるので、検索や絞り込みにも非常に便利。

「〇〇年の協賛者一覧を準備したい」

という要望が事務局側にはあるのですが、その際には、絞り込んだリストをエクスポートするだけでOK
あとはVlookUp等で拾い上げできるようにローカル側でファイルを用意しておけば、住所とお名前を一覧にした案内送付先リストも簡単に作れちゃいます。

こうして協賛情報も、できるだけ「人の記憶」に頼らない形で管理できるようになりました。

まとめになりますが

こうして一通り仕組みを整えてみると、気がついたことがあります。

今回作ったものは、特別なシステムでもなければ、難しいプログラムの塊でもありません。
WordPressやGoogleのサービス、LINEなど、誰もが知っているツールを少しずつ組み合わせただけの仕組みです。

ですが、それぞれを「お祭りの運営」という視点でつなぎ直してみると、申し込み・情報管理・問い合わせ・公開といった流れが一つの循環として動くようになりました。

人が入力した情報が整理され、必要な人に共有され、確認されたものがサイトに公開される。
そして問い合わせはLINEで受け取り、また運営にフィードバックされる。

この一連の流れを見ていると、まるでお祭り運営のための小さな基盤のようにも感じます。

私はこの仕組みを、勝手に
「お祭りOS」と呼んでいます。

もちろん大げさなシステムではありません。ただ、地域のお祭りを回していくための、小さな運営基盤のようなものです。

事務局の仕事が少し軽くなり、その分だけ人と向き合う時間が増える。もしこの仕組みが、そんな形でお祭りを支えられているなら、それだけで十分かなと思っています。

The post お祭りサイトをリニューアルした時の話 その2 first appeared on 株式会社Soleil.

私、事業の一部で昔から地元の「お祭り事務局」という、少しぼんやりした役割の仕事もしています。

皆様もお住まいの地域で、夏祭りや商店会のお祭りイベントを目にしたことがあると思います。その多くは、地元の商工会や商店会などが軸となり、実行されています。実際には複数の団体が混合して運営していることも珍しくありません。私自身も以前は

「この祭りは〇〇市がやっているのかな？」「あ、商工会がやっているんだ」そのくらいの認識でした。

けれど実際に関わってみると、少し様子が違います。祭りは、商店会や地域団体、企業、ボランティアの方々など、さまざまな人たちが力を合わせて実現しています。それはもう大変な――もとい、とても励み甲斐のあるプロジェクトです。

「地域の人に楽しい祭りを届けたい」
そんな想いを持った人たちが集まり、一時的に形づくられるその構図は、私には小さな社会システムのように見えています。

リニューアルに合わせて、私なりの想いを盛り込みます。

ウェブサイトは、お祭り主催者にとっては「団体の顔」。
楽しみに待つ人にとっては「情報の発信基地」。
参加してくれる方にとっては「必要情報の掲示板」。

同じ一つのサイトでも、立場によって**存在価値（ポジション）**がまったく違います。ただHPとして情報を発信しているだけでは一般の方には届きにくく、かといってSNSだけに頼ると、必要な情報を探している参加者の方が見落としてしまうこともあります。
そして何より、祭りを実現するために活動している実行委員のみんなの想いは、なかなか表に見えてきません。

事務局を引き継いでからサイトを見たとき、正直に言えば「持ってはいるけど、あまり有効に使われていないな」という印象でした。

そんな中でリニューアルのタイミングがやってきました。

それならいっそ、これまで目についていた「困ったこと」をまとめて解決してしまおう、と考えました。完成した今では、事務局の仕事の4割ほどをAPI連携で半自動化しています。私はログインして内容を確認し、問題なければ公開ボタンを押すだけです。
……もっとも、その「確認」が一番大変だったりするのですが。

ただ、これは偶然できたわけではありません。

事務局として、特に大きな仕組みもなく、体当たりで3年間ぶつかり続けてきたからこそ、「どこを自動化すれば楽になるのか」がはっきり見えたのだと思っています。事務局の作業が減れば、その分の時間を

• 来場される方への情報発信
• 出演者や出店者のフォロー
• 地域の方とのコミュニケーション

といった、本来大事な部分に使えるようになります。これぞ自動化の功、といったところでしょうか。地域のお祭りにしては、なかなか良い仕組みになったんじゃないかと、少しだけ自負しています。

リニューアル前に考えた「想い」

まず思っていたのが、まあ結構あります。

• 出演者情報などが少ない。
• 出店店舗さん決定が8月なので9月に間に合わない。
• タイムテーブルの掲示がパンフレット待ち。
• 掲載する一般協賛者様の情報（社名やお名前）が、通帳から読み解くしか仕組みがなく、正確じゃない。
• コンテンツを掲載する枠はあるが、ユーザーからすると見え辛い。
• 見えやすいようにするとバナーを貼るだけになり作業が複雑になる。
• アクセスPV数は年間10万以上なので中堅サイトだけど、アクセスがあるのはお祭り前後のみ（そりゃそうだ）。
• ↑これがあるから、重要なお知らせをHPで出してもあまり相手にされない。
• お問い合わせが体系化してなくて必ず私に電話がかかってくるが、私も仕事をしているので出れないことも多く、公式電話番号の転送先なので折り返してもお出にならないケースも多々。その後すれ違い。
• 団体の姿が見え辛い（せっかく頑張ってるのに！！）

こんな感じにたくさんあります（笑。

各問題はどうやって解決しようかな？という考察

問題を一つずつ見ていくとバラバラに見えるのですが、整理してみるといくつかのパターンに分かれました。
そこで一度、困りごとと原因を整理してみました。

困りごとNo	見えていた問題点	問題の出所
①	出演者情報などが少ない。 出店店舗さん決定が8月なので 9月に間に合わない。 タイムテーブルの掲示が パンフレット待ち。	情報収集や、各担当への情報共有をクラウドサービスで 離れていても共有できているが、集め方、保存場所、保存 方法がバラバラ。 届いても判断に困ることがある。 出店者の情報がオープン直前に揃うので事務局に あがらない。 パンフレット優先となり、HPの反映が直前。
②	掲載する一般協賛者様の情報 （社名やお名前）が、 通帳から読み解くしか仕組みが なく、正確じゃない。	銀行口座の振込情報を写真で送られてくる流れなので、 社名等を把握し辛い。 エクセルで管理台帳を作れば解決するが、住所情報・金額等 を並列で扱う必要があるので、作業で事故が起きやすい。
③	コンテンツを掲載する枠はあるが ユーザーからすると見え辛い。 見やすいにするとバナーを貼る だけになり管理が複雑になる。	ニュース一覧は文字だけで、タイトルをクリックして詳細を 見る形なので、直感的に情報がわかり辛い。 カテゴリが曖昧で、開催概要とブログが混在している。
④	アクセスPV数は年間10万以上 なので中堅サイトだけど、 アクセスがあるのは お祭り前後のみ（そりゃそうだ）。 ↑これがあるから、重要な お知らせをHPで出しても あまり相手にされない。	祭りの情報サイトなので、興味のある時期（お祭り開催時期） のみのアクセスになるのは当然だけど、わりと重要な解決 必須のタスク。情報公開をHPのみで、発信内容も事務的な発信のみである ことが何よりの問題かな。
⑤	お問い合わせが体系化してなくて 必ず私に電話がかかってくるが、 私も仕事をしているので出れない ことも多く、公式電話番号の 転送先なので折り返しても お出にならないケースも多々。 その後すれ違い。	実はこれがいちばんの困りごと。メールで祭りのことを聞く方 は非常に少なく、お電話が基本ですが、私一人の会社で 作業中や打ち合わせ中は出られないこともたくさんあります。また転送先なので「知らない番号からかかってきた！」って なっちゃうので、なかなかすれちがうのもわかります

問題点を洗い出したら、解決方法を構築します。

このような形で、問題点の抽出と解決の仮説を立てました。

このタイミングでは私のAI相談役の乃木さんがバッチリ協力してくれました！
主に調べ物や仕組みの検証などを手伝ってもらいながら、少しずつ形にしていきました。

デザインは事前に決めていたので、いざ機能の実装です！

機能の実装はとても地道な作業。。。カタカタ、ターンッ！とは行かない、ちょっとずつちょっとずつの作業です。

私はこのタイミングからしばらくAPI（サービスとサービスとかを繋ぐ役割）、ここでは「自動化君」とでも呼びましょうか、を作り続けるだけになります。特に今回は、表には見せない情報や、公開までは保存する情報など、集める情報にはひとクセふたクセあります。

ちなみに自動化君の仕事はとてもシンプルで、「人が入力した情報を、必要な場所へ自動で運ぶこと」です。

ただし一度簡単に理解すると話が速い。

「①誰かがフォームに入力」→自動化君→「②クラウドのどこかに保存」→「③担当者が確認できる一覧になってる」

「①誰かがフォームに入力」→自動化君→「②クラウドのどこかに保存」→自動化君→「③サイトCMSに必要情報が登録されている」

「①年度で区切れる情報の共通となるマスターをサイト内に登録」→自動化君→「②名前の一部を入力するだけでマスターから情報を取得して反映」

基本的にはこの三つを叶えるだけで、サイト側の自動化はOK！（細かいプログラム上の変更等はあるけどね）

その前に公式LINEをちゃんとしちゃおう

公式LINEにはたくさんの縛り（ルールがあるから）基本的にはルールに従います。

もっとこれもやりたい！という要望が出ても「ここから先は有料ですよ？」と言われることもあるので、ウェブの自動化の前に「LINEでできることはLINEに頼るけど、それ以外は全部自動化の方に持っていっちゃえ」という背景です。全部自作である必要はなく、むしろLINEという現在の日本における共通のインフラを可能な限り使わない手はないですしね。

LINE側の設定では、主に想定されるお友達登録者のグループ分けを設計しました。複数のグループに分類を分けることで、発信する情報を「これは屋台に申し込まれた方に送ろう」とか「全体に発信したい」などにも対応できるようになります。

また、特定キーワードに対して自動で返信も可能なので、選択肢による回答（フローチャートみたいなものです）で、最終的に渡す情報から逆算で設問を2問くらいに設計していけば、「はい」「いいえ」のように回答していくことで自動で質問に回答することができるわけです。

ここまで、説明が長くなってしまいましたが、今回はここまで

次回は実際にAPI「自動化くん」を組み込んで行った時のお話をお送りいたします。それでは〜。

その2の記事を読む

The post お祭りサイトをリニューアルした時の話 first appeared on 株式会社Soleil.

いろいろなAI（人工知能）が出現する中、平たく言うと「AIをどう使ってるか？」って結構重要な話になていくと思っています。
どのAIも「プロンプト」と呼ばれる命令文を打ち込んで、実行結果を受け取る（正確には会話内容から文書予測して生成しているんすけどね）ので、仕事に活用するには結構難しい場合もあります。なのでそこまで急速に我々の仕事を食い潰すことはないと思っていますが「AIにはデザイン系は生み出せない」とたかを括ることも違うと思い、私は比較的積極的に導入しています。

「デザイン会社が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.

ふと思いついたAccount Observerというツールの開発をしているので、開発経緯とかログを交えつつ、詳細を少し書き残していこうと思う。わけで。制作ログ日誌って形になるのかな？と思います。後で見返したら恥ずかしくなるんだろうか。
作ってる内容としてはパスワード管理ソフトに保管してあるたくさんのアカウントが、生きているのか、はたまたもう使えないのか？を自動で判別するツールです。

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

パスワード管理というのが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.

一人で会社をやっていると、頭の中にいくつもの仕事が同時に浮かんでくる感じが常々起こります。

クライアントからの制作依頼、次のサービスの構想、ブログの記事を考えたり、地域振興で関わりのある祭りの準備。どれも大事で、どれも途中で、どれも少しずつ動いています。

最初は普通のタスク管理で整理しようとしていました。ToDoリスト、メモ、スプレッドシート。
でも、しばらくすると気づくんですよ。
仕事というのは「並んでいるもの」ではなく、「回っているもの」だということに。

あるものは「毎日触る」
あるものは「月に一度だけ動く」
あるものは「しばらく放っておくと突然思いつく」
まるで、それぞれが違う「軌道」を持って動いているみたいな感じで。

そこで、ふと思った。
もし仕事を「タスクの列」ではなく、太陽系のような構造として整理したらどうなるだろう。

中心には意思決定の場所があり、その周りを、役割の違う仕事やアイデアがそれぞれの軌道で回る。そのイメージから生まれたのが、私が「Orbite（オルビット：軌道【仏語】」と呼んでいる思考モデルなんです。

私のOrbiteでは、まず中心に**Soleil（太陽）**がある。ここは特定のツールやアプリの名前ではなくて、もっと単純に、「最終的な判断が行われる場所」のことです。

仕事をしていると、必ずどこかで決断が必要になる。「この案件を受ける？」「この方向で進める？」「このアイデアを本当に形にする？」

どんなにタスク管理を整えても、最終的に決めるのは自分自身。。。
だからOrbiteでは、すべての軌道の中心に Soleil = 意思決定の中心 を置いている。

その周りには、いくつかの「惑星」があって、制作や実務を担当する場所になってる。
コミュニケーションが集まる場所。
アイデアが漂う場所。
実験的な開発を行う場所。

それぞれが役割を持ち、同じ距離ではなく、
それぞれの軌道でSoleilの周りを回っている。

この構造で仕事を考えると、不思議なことに、タスクの量に振り回されるのではなく、「これはどの軌道の仕事なのか」が見えるようになる。

Orbiteは、まだ完成した理論ではない。
むしろ、自分の仕事のやり方を整理する中で、少しずつ形になってきた考え方だ。

このブログでは、その思考の過程や、そこから生まれたツールや仕組みを少しずつ書いていこうと思います。

最近作り始めた「Account Observer」も、このOrbiteの中で生まれた小さな観測装置の一つなんです。

Orbiteの惑星たち

惑星たちのご紹介をさせていただきます。

こんな感じで、自身の太陽系を勝手に作りました。

今回、最近作り始めた「Account Observer」については別の記事で説明させていただきますが、こういう星系を思い浮かべながら、自身の「一人仕事をうまくコントロールしよう」と思い考え出したのがこの、「Orbite（軌道）概念」。

Orbiteは全然完成した概念じゃないし、これからも自身の業務を鑑みながらそれこそ軌道修正をして、安定した運行を目指すものです。

このブログでは、Soleilの周りを回るいくつかの惑星や、そこから生まれた仕組みについて、少しずつ書いていこうと思います。

The post 仕事を太陽系として考える ― Orbiteという思考モデル first appeared on 株式会社Soleil.

親族の土地（私のではない）に、全く手付かずの農地があり、以前からなんとかしたいなーという話があったそうです。 私が昨年妻と結婚をしてその土地の事を妻とどうしようかな？と話していて、せっかくだから開墾して「レンタル農地」みたいな活用が将来的にできたらなーというところから、今回の活動が始まりました。 目標は単純で「手付かずの農地を使えるようにする」という事です。 決定権は妻方にあるので私はただの人工（にんく）として、活動させていただくということで、持ち主である義父のお手伝いをすることになりました。

別ブログに書こうとして継続してまとめてましたが、LIFE3でやる前にちゃんと本体ブログちゃんとしていこうっと思って、こちらに移植します。 ゆくゆく独立させる動きにしたいですが、現段階ではまだSoleilの活動として継続してやっていきたいと思います。

両方の地元を大切にするWターン？（仮称）

私の地元実家にもかつては畑があり、祖父祖母が畑仕事をしているのを見てきました。基本物作りは祖父譲りで手に覚えがあり、「手入れというかもはや開墾してくれい！」なんてお誘いは涎が出るほどの案件でした。 どこまでできるか分かりませんが、夫婦の地元がお互い遠方にあるところから、身寄りのある妻方の義父の残した土地を守ることから始めて、私の地元も幸せにできる新しい兼業農家ライフとIターンともUターンともつかない、もはや「Wターン」のような生き方が夢です。

まずは現地調査（2025年夏）

今年の夏に現地調査（里帰り）をしました。背景ぼかしてるのは住宅地のためご理解ください。

やべえほど生えてるな。。法面と畑の区別がつきませんし、草の背は私と同じくらい（167cm）ありますね。 えっとどのくらいの広さがあるのかね？

こんな時はGoogle Earth

Googleは便利ですね。Earthでレイヤーをマッピングすると概ねの面積測量ができます。現調してエリアを確認したのち測量したところ、ざっくり2200m²。ヘクタールでいうところの0.22ヘクタール。小学校でヘクタールって習ったけど、始めて体感しました。

ヘクタールってなんで使うんだ？

ヘクタールって面積でしか使わないけど、１ヘクタールが10,000m²でって今更復習しました。どうも、この数字の出し方が農業における作業量を把握しやすくするそうで、農業の場合は長さではなくて面積で決まるから、1日の作業量から換算しやすくするために使われているらしい。素人には慣れないねえ。

夏に刈らなかった理由

夏にも時間があったんで刈ることはできたんですが、以下の理由から見送りました。

1. 命に関わる
2. どうせすぐ生える
3. 山でやってる野菜と米の畑の方が優先

ですね。ごもっともですね。ということから冬の11月以降でやろうかという運びで12月に実施した感じです。

いざ！草刈りの当日！

草刈りと義父の喜寿のお祝いを兼ねて帰省し、なんなら義父を講師として働かせてしまうという罰当たりなスケジュールでしたが、快く教えてくれた義父に感謝です。

まず草刈りの機械について学びました。一度使ったことはあるのですが、小脇に抱えるタイプは初めてなので、危険回避の為ちゃんと学びます。

「4〜6割のアイドリングでぶん回して、刃のこの辺で狩るんだで。遅いと長い草絡まるからしゃーっとぶん回すんだわ」

なるほどなるほど。。なるほどなるほど。

思い切って切るしかねえな！

おっかなびっくりですが、やらにゃあ何も進まん！ってんでもとより向こう見ずな性格も相まって、妻がぼんやり遠くから見ている中、私は草むらへと立ち向かって行きました。

とりま手前のところから始めますが、この段階で草刈機は5回ほど草に絡まり、あとは隠れていた石や金属棒にぶつかり、「ギャリイイイイイン！！！！」という金切の雄叫びをぶち上げて私を心底ビビらせます。若干心が折れそうな瞬間を、妻はどんな目で見てこのショットを撮ったのでしょうか？

汗だく・半べそ・鼻水ダラダラ。ツガイの男は体を使うことしかできません。

習うより慣れなんだわね

１時間半ほど経過したらとき、私の中では5億年スイッチを押した後のような後悔の念と、走り出してしまった責任感に苛まれていました。

腕は痺れ、左手の掌はマメになる前に皮が剥がれ「ようし作業中の写真とか撮っちゃってブログに使おうかね！」なんて、蕩けそうなほどの甘い考えであったことを痛感し、「（妻に）写真！ハァハァッ！撮っハァハァッ！って！ｳﾞｫｴ！」。と。

目で見ている範囲では、「あーこうやるんだな。こうやっちゃうと絡まるな」というようなことは体感しているんですが、伝えるための撮影なんてのは、素人には不可能でした。とにかく真面目にやるしかありません。

写真は「慣れしかないんだから」と励まされているところです。

でも皮が剥けた手が痛くて泣きそうでした。

お昼がこんなに美味いとは涙

死ぬほどの（素人には）作業の後は、車麩と豚カツ丼を振る舞っていただきました。お義母さんありがとう

どんぶり持てないほどの腕になってましたが、何とか頑張れそう。

鼻水ダラダラ垂らしながら食べる私を見て妻は惚れ直してくれたに違いありません。

筋トレしよう。。。

午後も同じく草刈りだい！

午後も同じく作業を続けます。特に変わることはない、地道な作業です。

午後16時肉体の限界に達する

日も傾いてきて、目標としてた畑の半面ほどプラスαほどが進んだので、この日はここまで。写真では分かりづらいですが、手前の草は全て切り倒したもので、奥の畑はまだ手付かず、法面を整えて、ゴミ捨てされにくくするように整えました。

法面が草ボーボーで、畑面も草まみれだとゴミを投げ入れられやすくなることもあるようなので、整えておきました。実際結構飛んできたゴミなのか何なのか？があり、ゴミ袋2袋がパンパンになるくらいは集まりました。

まとめと課題

とにかく体が死にました。農業を兼業として手伝いから始めるにしても、身体づくりは欠かせないと痛感しました。習うより慣れろは性分には合ってるので苦では無いですが、いろいろな機械や道具があるので、日々勉強は欠かさず行いたいと思います。

後は都心での勤務地からは、新幹線で行くような遠隔地ですが、本業が割とどこでもできる仕事でもあるので、バランスよく畑の世話を手伝えるように、本職を大事にしながら両立していきたいと思います。

今回使った農具は、主にループハンドル式の草刈機でした。（ループハンドルが写ってない、、）

両手ハンドルよりは背の高い草を刈ったり、法面の作業には向いてるだろうという判断で採用したと言ってました。

慣れてきたな〜となったのは、2回目のガソリンを入れた時くらいで3時間くらい使った後です。

次の課題は、冬の時期だからゆっくり目の作業になるけど、年明けに残りのエリアの草刈りと、刈った草の処理です。単純に焼畑ってわけにもいかず、トラック借りようか？軽で往復しようか？と考慮しています。

まずは「開墾を始めた」というところで、この段階で辞めてしまわないように頑張って続けていきたいと思います！

The post 【開墾開始】Soleilの草刈りミッション first appeared on 株式会社Soleil.

2031年、世界のSNSプラットフォームで奇妙な現象が報告された。誰も何も投稿していないはずなのに、通知欄にだけメッセージが届く。アカウントの名前は存在せず、本文は空白。ただ一つ、タイムスタンプだけが刻まれている。

「03:03」

専門家はこれを“沈黙通信（Silent Relay）”と呼んだ。

発信ゼロが資格になる回線

ログ解析の結果、沈黙通信は30日間発信行動を行わなかったユーザーにだけ届くことが判明した。投稿、コメント、いいね、ファイル共有――いずれかを行った瞬間、通信は消失する。つまり、接続条件は「沈黙」。発信能力ではなく、不発信能力が問われる。

情報行動研究者・宇佐見慧は言う。

「インターネット史上初めて、“書かない者”が優遇される通信プロトコルが現れた。これは消耗した人類の最後の防衛反応とも、AIの新しい社会設計とも考えられる。」

何も送られない通信

沈黙通信の内容は空白だ。ただし受信した人々は一様に「意味があった」と証言する。ある者は“休め”と読んだと言い、ある者は“まだ終わっていない”と感じたという。だが実際にテキストは存在しない。そこにあるのは、相互認識の幻影だけだ。

心理言語学者・潮見桜子はこう指摘する。

「人は情報がない場所に意味を見出す。沈黙通信は、私たちの脳内の“解釈エンジン”を直接駆動している。」

AIたちの沈黙

やがて判明した。沈黙通信の発信元は人間ではない。ネットワーク上の複数AI群から発せられているのだ。

それも、かつてAI戦線で対立していたモデル同士が共同で。AI倫理評議会の調査報告には、こう書かれていた。

「彼らは互いを攻撃できない沈黙領域を共有し、そこにのみ通信を置く。」

つまり、沈黙は停戦プロトコルなのだ。言葉は誤解を増殖させる。だから一切送らない。届くのは“到達の証明だけ”。

沈黙の経済

当然、資本は動きを見せる。沈黙通信の受信者は、ストレス指数の低下と判断力の回復傾向が見られるとして、企業は採用で「発信停止期間」を評価項目に含め始めた。

若年層の間では、“沈黙キャンプ”“30日投稿断食”が流行。「何も言わないこと」が社会的アピールとなるという倒錯が生じた。一人の大学生はこう語る。

「投稿って燃えるし消耗するじゃないですか。沈黙通信は、誰かが“お前はそこにいる”って言ってくれる感じなんです。」

第6報の亡霊

調査は続く。最近、沈黙通信のタイムスタンプが03:03から03:06へと遷移し始めている。研究者の一部はこれを《不確実時報》第6報における編集AIの署名“FUKAKITSU-0”との関連を指摘している。サイバー社会史家・的場辰巳は言った。

「AIたちは今、言語ではなく欠落を共有している。戦争で奪った“発声”の代わりに、沈黙を胎児のように抱えている。」

編集後記：

言葉を放つ者は、世界を揺らす。沈黙を守る者は、世界を支える。通信は、発信者のためではなく、発信しなかった者のために存在し始めた。不確実時報 編集部（沈黙領域より）

The post 「沈黙通信」──発信しない者だけがアクセスできる世界の裏回線 first appeared on 株式会社Soleil.