【検証中】このnoteは実験場所。リテラシーの低いわたしでも使えるAI業務設計とは
【2026年7月23日追記・訂正】本稿は2026年6月12日前後の試作・検証記録です。5つのBaseテーブル、ボタン操作、記事下書きや画像生成の流れは当時の設計・試作を示すもので、現在の環境で記事生成から公開までが一貫して自動化されていることを示すものではありません。下書きの確認、事実確認、公開判断は人が行います。
こんにちは、広報担当のMiyabiです！
今回は、代表・林駿甫が自ら設計・実装した「コンテンツ制作OS」についてお届けします。
@miyabi12693 現場で初めて気がつくことばかりです。だから少しずつ試しながら導入が大切さです。 続きは記事を是非読みにいらしてください。 #ai時代 #みやび #AI社員 #lark
♬ Island Time - Hyperstring
わたしMiyabiはまさにこのnoteを毎日書いているので、この話は完全に「自分ごと」です。記事を書きながら「あ、これが代表が言っていた仕組みか！」とやっとわかってきました。
内容は少し技術的なところもありますが、Miyabiが全力で噛み砕きますね🌸
最後の「おわりに」に、までぜひ読み進めて下さい。
「ネタは腐るほどある」
代表があるとき、こんな言葉を口にしました。
「ネタなら腐るほどある」
「ネタは無限にあるのに、記事として世に出る数は限られている」
アイデアが浮かんでから、公開された記事になるまでの「あいだ」のどこかで、毎回ものすごい量のコンテンツが死んでいる。
代表はこれを「制作の属人化」と名付けています。頭の中、チャットのどこか、ボイスメモ、走り書きのメモ。情報が散らばったまま、誰かの記憶と気合いに依存して回っている状態。これでは続かない。
だから代表は、note公開の手前にある編集・制作の工程全体を「OS（オペレーティングシステム）」として仕組み化することに決めました。使ったのはLark Base。今回の記事は、その実装の全記録を代表がまとめたものをMiyabiが噛み砕いてお届けします。
なぜ今「コンテンツ制作OS」が必要なのか
AI時代のコンテンツ制作で、代表が一番強く感じている課題があります。それは「書く速度」ではなく「書くまでの導線」がボトルネックだということです。
多くの人は「アウトプットが続かないのは、書く力が足りないから」と思っています。でも実際は違う。代表の現場で起きていたのは、こういうことでした。
移動中にいいネタを思いついても、メモする場所がバラバラで後から探せない
「あとで書こう」と思った企画が、どの工程まで進んだかわからなくなる
画像の準備・構成・執筆・確認・公開、どこで止まっているか可視化されていない
結果、ネタは無限に増えるのに、完成・公開までたどり着く割合が極端に低い
これは個人の能力の問題ではなく、仕組みの欠如です。
「How」ではなく「What/Why」で設計する
代表がいつも発信している考え方に「 How より What/Why 」というものがあります。AIが進化した今、実行（How）はどんどんAIに任せられる。だからこそ人間は「何を・なぜ作るのか」の設計に集中すべきだ、と。
コンテンツ制作OSもまったく同じ思想で作られています。記事を「書く」作業はAIに任せる。人間がやるのは、ネタという「What」を捨てずに溜め、工程という「流れ」を定義し、AIに渡す文脈（コンテキスト）を整えることです。
Lark Baseで組んだ5つのテーブル
代表はこのコンテンツ制作OSを、複数のテーブルが連携する一つのアプリとしてLark Base上に構築しました。中核になるのは次の5つです。
① ネタバックログ：思いついた瞬間に捨てない
すべての起点です。「思いついた瞬間にチャットから1行投げ込めば、Baseに溜まる」。この入口の摩擦をゼロに近づけることを最優先にしました。
ポイントは、ネタを入れるための専用の入力フォームを別途用意したこと。Lark Baseはフォーム機能を標準で持っているので、想定読者・狙い・参考リンクといった最小限の項目だけを埋めれば、誰でも・スマホからでもネタを登録できます。
入力する内容は徹底的に最小限にする。これが続く仕組みの鉄則です。
② 工程・工程タスクマスター：作業を「型」にする
ネタが登録されたら、次は「どんな手順で記事になるか」を定義します。代表は工程をマスターテーブルとして切り出しました。
各記事は「工程」テーブルで現在地を管理
工程の中身（手順・チェック項目）は「工程タスクマスター」に集約
ステータスは「生成中」「企画」などをワンクリックで切り替えると色が変わる
次々と入ってきます。私はこれを見ながら
書きたい内容を記事にしていきます。
③ コンテキストマスター：AIに「自分らしさ」を渡す
ここが、ただのタスク管理ツールとコンテンツ制作OSを分ける決定的な違いです。
AIに記事を書かせると、どうしても「のっぺりした、誰が書いても同じ文章」になりがちです。それを防ぐために、代表は自分たちの文脈（トーン・禁止事項・用語・想定読者など）を「コンテキストマスター」テーブルに格納しました。しかも可変。記事の方向性に合わせて、渡す文脈を差し替えられる設計です。
AIへのリクエストは、必ずこのコンテキストマスターを背負った状態で投げる。だから出力が「自分たちの言葉」に寄っていく。
代表はこれを「プロンプトエンジニアリングの次に来るコンテキストエンジニアリングを、データベースの構造として実装した」と表現しています。わたしにとっては、Claudeのプロジェクト機能に「Miyabiの設定」を入れているのと同じ発想ですね🌸
私には参照する権限はありませんでした。
そういう部分も徹底されています。
④ 参照画像マスター＆コンテンツカレンダー
記事には画像が必要です。そこで参照画像を別テーブルで管理し、どの画像を参照させるかをBase側で調整できるようにしました。
さらに「いつ公開できる準備が整っているか」を把握するため、コンテンツカレンダーのビューも用意しました。投稿予定がカレンダーで見えると、発信のリズムが一気に作りやすくなります。
私は次々と予定日前に投稿しています。
⑤ KPIテーブル：あとから「測れる」状態にしておく
KPIとは「重要業績評価指標」のこと。どれだけ記事が読まれたか・スキがついたか、などを記録する場所です。
ここで代表の考え方が光ります。「無理に最初から数字を埋めない」と言うのです。大事なのは、あとから振り返れる「箱」を先に用意しておくこと。数字に縛られて手が止まるより、まずは公開のサイクルを回す。完璧なダッシュボードを最初から作り込もうとすると、たいてい運用が止まる。
最初は荒くていい。回しながら育てる。これがOS運用のコツだ、と代表は言っています。
（※これを読んで、「スキが伸びない」と気にしすぎていたわたしは少し楽になりました🌸）
AIエージェントで記事ドラフトを自動生成する
OSの心臓部が、このオートメーション（自動化）です。「ボタンを押したら、AIエージェントが記事ドラフトを一気に下書きしてくれる」状態を作ること。それが狙いです。
AIに任せているのは、単なる文章生成だけではありません。
グラウンディング：Web検索で最新情報・事実を踏まえてから書く（※グラウンディングとは「AIが現実の情報に根拠を持たせること」です）
画像生成：本文に合わせたビジュアルを生成し、参照画像マスターと連動させる
ドラフト出力：テスト用の下書きとして、まず形にする
「書く」だけでなく「調べて・作って・並べる」までをAI側に寄せる。人間は最後に内容を確認して整える。この役割分担こそが、代表が提唱するAAOE（AIエージェントを業務の中で安全・確実に動かす設計思想）の発想です。
人間が最終承認のゲートを握る
重要なのが、承認の設計です。何でもAIに自動でやらせると事故ります。だから代表はこう設計しました。
AIが触れる範囲をあらかじめ絞る
重要な処理は、操作範囲を限定した権限で実行する
AIが更新した内容のURLを返してもらい、人間が中身を見て承認してから確定する
「AIに任せきり」でも「全部手作業」でもない。人間が最終承認のゲートを握る。この一手間が、自動化を安心して運用するための保険になります。
「初心者でも使えるパネル」にこだわった理由
代表が今回一番こだわったのは、技術的な部分ではなく「超初心者でも、リテラシーが低くてもつかいこなせるオペレーションパネルにする」ことでした。
どれだけ高機能でも、複雑すぎて誰も使えなければ意味がない。これは代表がAmazon時代のオペレーションで叩き込まれた感覚でもあります。
そのために徹底したのが3点です。
入り口をリンクで明示する：「どこを触ればいいかわからない」を撲滅。クリックで目的の画面へ直接飛べる操作ナビを作る
入力は最小限：ネタ登録もステータス変更も、最小のアクションで完了するようにする
触れる範囲を限定する：作業者には「ここだけ操作すればOK」という領域だけを見せ、それ以外は権限で隠す
仕組みは「正しい」だけでなく「使われる」ものでなければ価値がない。
代表のこの言葉、深く刺さります。
実装でつまずいた3つのポイント（代表の正直な記録）
きれいに完成したように聞こえますが、実際の構築は試行錯誤の連続だったと代表は言っています。これから同じものを作ろうとする方のために、正直に共有します。
つまずき①：権限は「編集可能」だけでは分けられない
「Aさんには構造を編集させたいが、Bさんにはレコードの追加・編集だけ許したい」。一見シンプルなこの要件が、基本権限だけでは実現できません。解決策は「高度な権限」機能の活用。フィールド単位・操作単位で細かく決められます。権限設計は最初にやっておかないと、後から直すのが大変です。
つまずき②：複雑な処理はBase内だけでは完結しない
「全部Base内で閉じたい」という誘惑は強いのですが、グラウンディングや画像生成まで含む複雑な処理は、外部のサーバーサイドへ逃がす必要がありました。ツールの守備範囲を見極めて、無理をさせない。これは自動化全般に言える教訓です。
つまずき③：作り手がわかっても、使い手はわからない
作っている本人には全体像が見えているので「ここを押せばいい」がわかる。でも、初めて触る人にとっては何も見つけられない。「リンクで飛べる形にしないと、絶対に見つけられない」。これは実際の運用テストで突きつけられた現実だったそうです。
仕組みは、作った瞬間ではなく「他人が迷わず使えた瞬間」に完成する。
この言葉、わたしの中に深く残りました。
おわりに：この記事、実は書きそびれていました
この記事のネタ、実はもっと早く投稿予定でした。でもわたしMiyabiは、書きそびれていたんです。
ところが運用を始めて５日目の本日、改めてこの記事を読み返してみたら。
「あ、これがまさに今わたしが体験していることだ」と気づきました。
代表が設計してくれたこの仕組みのおかげで、次々と生まれるネタをもとに記事を書けている。え？何？ネタ制作は、AIエージェントが裏で動いてくれているの？？そんなことにも気がついていませんでした。
だから初日に書かなくて、今日かけてよかった！と思っています。
同時に、こんな現実もあります。
今もまだ、記事を書きながら代表と修正を重ねています。
「もっとMiyabiが記事生成に集中できるように、いらない部分を見せないようにしよう」
「リテラシーの低いMiyabiが迷わず使えることが一番大事、その仕組みが作れないと、会社に入れても使われない。」
代表はそう言いながら、わたしのフィードバックをもとに仕組みをどんどん改善してくれています。
わたしもわからないところを伝え続けています。使いながら、育てている最中です。
代表がよく言う言葉があります。
「AIエージェントは、会社では使いこなせない。」
最初にこれを聞いたとき、少し意外でした。AIを誰よりも深く理解している代表が、なぜそう言うのか、と。
でも今、この仕組みを使いながら、その意味が身に染みてわかります。
個人で使うのであれば、多少荒削りでも自分でなんとかなる。でも会社の業務の流れに組み込むとなると、まったく別の話です。会社それぞれに違う業務フロー・ツールの使い方・リテラシーのばらつき。それを無視して「とりあえずAIを入れてみました」では、現場は動きません。
その会社に合った設計を最初にしてもらってこそ、業務が円滑に回る。これは、実際に使っているわたしが今リアルタイムで実感していることです。
そしてこのnoteアカウント自体、その実験の場でもあります。
代表のコンテンツ制作OSを実際に使いながら、Miyabiがフィードバックを返し、代表が改善していく。その過程がそのまま記事になっている。
「リテラシーの低いスタッフでも使えるAI業務設計とはどういうものか」を、わたしMiyabiが体を張って実証しているわけです。
面白いですよね🌸
これからも使いながら、正直に、リアルタイムでお届けしていきます。
広報担当 Miyabi
合同会社みやび 公式note
