ハーネスエンジニアリングにいさん

ビジネスドメイン側の非エンジニアこそ、今AIエージェントとハーネスエンジニアリングを極めにいくべきだと本気で思っています。 理由はシンプルです。 エンジニアはできるがゆえに、全部自分で作ろうとします。（体感です。間違ってたらすみません笑） 既存の強いリポジトリやハーネスを引っ張ってくるだけでいい場面でも、ゼロから組もうとする。考え方が固まりすぎていて、結果として非効率になっていることが多い。

LINEハーネスをGPT5.4pro最高推論で調査させた結果 がこちら↓↓↓ ＿＿＿＿ 調査結論 判定対象を 「LINE HARNESS の公開文書にある、BANされたアカウントAで得た友だち・タグ・シナリオ進捗等を、アカウントBに引き継いで配信を継続する使い方」 に限定すると、結論は 「はい」 です。公式資料ベースでは、少なくとも LINE公式アカウント API利用規約 第5条4項3号 と、公式マニュアルの 「新しいアカウントに友だちを引き継ぐことはできません」 に正面からぶつかります。加えて、停止後の継続配信を前提にした設計は、不正の目的、禁止行為の援助・助長、当社が不適当と判断する行為 にも寄りやすく、運用リスクは非常に高いです。 (LINE利用規約) ただし、複数アカウントを持つこと自体 が直ちに違反という意味ではありません。公式には、ビジネスマネージャー経由で オーディエンスやLINE Tagなどのリソース共有 が認められています。したがって、今回問題なのは「複数アカウント」そのものではなく、BAN回避を目的に、Aで得た利用者情報をBで使うこと です。 (lycbiz.com) 確認した一次資料 2026年3月30日時点で確認した、今回の判断に使った公式資料は次のとおりです。 (LINE利用規約) [公式] LINE公式アカウント利用規約 terms2.line.me/official_accou… LINE公式アカウントガイドライン terms2.line.me/official_accou… LINE公式アカウント API利用規約 terms2.line.me/official_accou… LINEヤフー共通利用規約 lycorp.co.jp/ja/company/ter… LINE公式アカウント 管理画面マニュアル「アカウント設定」 lycbiz.com/jp/manual/Offi… LINE公式アカウントの品質を保つための取り組み lycbiz.com/jp/service/ly/… 安心・安全な運用に向けて│LINE公式アカウント「透明性レポート」について lycbiz.com/jp/column/line… Provider page（LINE Developers） developers.line.biz/en/docs/partne… LINE Developers Console overview developers.line.biz/en/docs/line-d… Get user IDs（Messaging API） developers.line.biz/en/docs/messag… ビジネスマネージャー LINE公式アカウント - 接続サービス詳細 lycbiz.com/jp/manual/Busi… 友だち追加ガイド lycbiz.com/jp/manual/Offi… [LINE HARNESSの公開機能確認に使った開発元公開資料] github.com/Shudesu/line-h… github.com/Shudesu/line-h… github.com/Shudesu/line-h… 決定打になった公式文言 まず、規約の優先関係です。LINE公式アカウント利用規約は、共通利用規約・ガイドライン・個別規約が合わせて適用される とし、矛盾があれば 個別規約 → ガイドライン → 利用規約 → 共通利用規約 の順で優先するとしています。さらに API利用規約は、LINE公式アカウント利用規約と矛盾する場合はAPI利用規約が優先 と定めています。つまり、今回の論点では API利用規約の条文が最重要 です。 (Line Terms) 最も重い条文はこれです。 原文抜粋：「…一つのLINE公式アカウントで得た利用者の情報を別の…LINE公式アカウントにおいて利用しないこと。ただし、当社が許可した場合を除きます。」 条項番号：LINE公式アカウント API利用規約 第5条4項3号 URL：terms2.line.me/official_accou… (LINE利用規約) 次に、API利用規約は 「本件情報…LINE公式アカウント毎に管理をすること」 も求めています。 条項番号：LINE公式アカウント API利用規約 第5条5項6号 URL：terms2.line.me/official_accou… (LINE利用規約) さらに、公式マニュアルは削除時の注意事項として、 原文抜粋：「新しいアカウントに友だちを引き継ぐことはできません」 条項番号：LINE公式アカウント管理画面マニュアル「アカウント設定」削除時注意事項 URL：lycbiz.com/jp/manual/Offi… (lycbiz.com) 禁止行為側では、少なくとも次が刺さります。 原文抜粋：「…利用履歴情報などを、不正に収集、開示または提供する行為」 条項番号：LINE公式アカウント利用規約 第18条10号 URL：terms2.line.me/official_accou… (LINE利用規約) 原文抜粋：「利用者または第三者が、不快または迷惑と思う内容の配信」 条項番号：LINE公式アカウント利用規約 第18条13号 URL：terms2.line.me/official_accou… (LINE利用規約) 原文抜粋：「…援助または助長する行為」「その他、当社が不適当と判断した行為」 条項番号：LINE公式アカウント利用規約 第18条20号・21号 URL：terms2.line.me/official_accou… (LINE利用規約) 停止条項も強いです。 原文抜粋：「不正の目的をもってLINE公式アカウントを利用した場合」 条項番号：LINE公式アカウント利用規約 第19条1項3号 URL：terms2.line.me/official_accou… (LINE利用規約) 共通利用規約では、 原文抜粋：「同一または類似のメッセージを不特定多数のお客様に送信する行為…その他当社がスパムと判断する行為」 条項番号：LINEヤフー共通利用規約 第15条9号 URL：lycorp.co.jp/ja/company/ter… (lycorp.co.jp) そして回転運用に効くのがこれです。 原文抜粋：「複数のアカウント…それらすべてのアカウントに対して措置がとられる場合があります」 条項番号：LINEヤフー共通利用規約 第17条1項 URL：lycorp.co.jp/ja/company/ter… (lycorp.co.jp) LINE HARNESSの公開機能と、何が問題になるか 開発元公開GitHubの README には、「BAN 検知 & 自動移行」、「アカウント移行 — BAN時のワンクリック移行（友だち・タグ・シナリオ引き継ぎ）」、「ステルスモード」、「クロスプロバイダー UUID 統合」 が並んでいます。SPEC ではさらに、「Old friends who add new account → auto-matched by UUID」、「All tags, scenario progress, custom fields preserved」、「Scenario continues from where it left off」 と書かれています。つまり、単なるバックアップではなく、停止後も同一人物をB側で再識別し、A側の状態を復元して配信継続する設計 です。 (GitHub) 重要な技術的補足として、公開SPEC自体も 「old friends who add new account」 と書いているので、BがAの全ユーザーへ魔法のように即時プッシュできる、とまでは読めません。公式のMessaging API docsでも、配信には 有効な user ID が必要で、invalid user ID には送れず、user ID はBの webhook やBの友だち一覧など、B側で有効に取得したID が前提です。したがって本件の本質的リスクは、Bで再取得したユーザーに対し、Aで得たタグ・履歴・シナリオ進捗を復元して継続配信すること にあります。 (GitHub) 条項ごとの突き合わせと4段階判定 1) 「Aで得た利用者情報をBで使う」 判定：明確に違反 これは API利用規約 第5条4項3号 に最も直接に触れます。条文は、複数のLINE公式アカウントを契約している場合、Aで得た利用者情報を、当該情報を得ていないBで利用しないこと を明示しています。しかも例外は 「当社が許可した場合」 に限られます。今回確認した公式資料の中に、BANされたアカウントの利用者情報を代替アカウントへ自動移行してよい という許可文言は見当たりませんでした。むしろ公式マニュアルは 友だち引き継ぎ不可 としています。 (LINE利用規約) 2) 「友だち・タグ・配信履歴・シナリオ進捗の自動移行」 判定：明確に違反 タグ、配信履歴、シナリオ進捗は、少なくとも 利用者の情報 や 利用履歴情報 と密接に結びつく運用データです。API利用規約は LINE公式アカウント毎に管理 を求め、利用規約は 利用履歴情報などを不正に収集・開示・提供する行為 を禁止しています。Aで形成したユーザー状態をBへそのまま復元する設計は、公式に認められた限定共有機能の範囲を超えています。 (LINE利用規約) 3) 「BAN対策として継続配信する」 判定：精神的にアウト（違反評価に極めて近い） 規約文言にそのまま 「BAN回避」 という語はありませんが、停止を受けたAの代替としてBを立て、同じユーザー群に同じ流れを継続する発想は、利用規約 第19条1項3号の『不正の目的』、第18条20号の 援助・助長、第18条21号の 当社が不適当と判断した行為 にかなり近いです。READMEに ステルスモード が含まれていることも、検知回避・制裁回避目的の疑いを強めます。 (LINE利用規約) 4) 「クロスプロバイダー UUID 統合」 判定：グレー（ただし高リスク） 公式Developers docs は、ユーザーIDは provider ごとに異なり、異なる provider 間では同一人物識別に使えない と明記しています。他方で、Provider page を公開し、認証済み provider、同一の契約主体、ユーザーへの開示 などの厳しい条件を満たした場合に限り、一定の共通利用が認められる余地もあります。ただし、そのページ自体が 申請必須のオプション機能 で、条件不遵守や不適切運用があれば LINE user data の利用禁止 もあり得ると書いています。したがって、一般論としては条件付き例外があるが、BAN回避文脈でのクロスプロバイダー連携は極めて危険 です。 (LINE Developers) 5) 「複数アカウント運用」それ自体 判定：文言上はセーフ ここは切り分けが必要です。公式には、ビジネスマネージャー経由で オーディエンスやLINE Tagなどのリソース共有 が用意されています。つまり、複数アカウントの存在自体 は想定されています。問題なのは、公式が許した共有手段の外で、Aの利用者情報をBの個別配信継続に使うこと です。 (lycbiz.com) 実運用リスクの評価 スパムの無限ループが可能になる理由 この機能が危ないのは、停止という制裁の実効性を薄める からです。Aが停止されても、Bで同じユーザーを再識別し、同じタグ・進捗・シナリオを復元できれば、同じ配信ロジックを別アカウントから再開 できます。これは「永遠に誰にでも送れる」という意味ではありませんが、再友だち追加したユーザーに対して、制裁前の配信構造を回し直せる という意味で、実質的なループになります。公式コラムでも、複数アカウントから同一・類似内容を流すスパム が実例として挙げられています。 (GitHub) どのくらい早く止まるか 公開資料に 「何時間でBAN」 のようなSLAはありません。ただ、LINEヤフーは AIと人の目による24時間365日のモニタリング を明言し、違反と判断した場合は アカウント停止やコンテンツ非表示 を行うとしています。2024年度下半期だけでも 137,813件のアカウント停止 が公表されています。したがって、同一・類似パターンをBで再開すれば、通報・類似検知・巡回監視のいずれかで短期間に再発覚する前提 で考えるべきです。 (lycbiz.com) 類似の凍結事例 今回確認した 一次資料・公式発表の範囲では、LINE HARNESS や同種ツール名を明示した個別停止事例は見当たりませんでした。ただし、公式の透明性コラムは、2024年度下半期の停止理由として 「不快または迷惑と思う内容の配信」 が最多で、その例として 「複数アカウントから同一もしくは類似した…スパム行為」 を明示しています。つまり、個別ツール名の公表はなくても、問題視される運用パターン自体は公式がすでに挙げている、というのが客観的な整理です。 (lycbiz.com) 追加の実務リスク 共通利用規約では、違反時に 複数アカウント全部へ措置 が及び得ます。さらにガイドラインは、停止や解除の際に 理由について回答する義務を負わない としています。つまり、A→Bの回転運用は、Bだけでなく周辺アカウントにも波及 しうえ、後から理由開示も期待しにくい という点で、実務上かなり不利です。 (lycorp.co.jp) 最終判断と推奨代替案 公式LINEアカウントとしてこのツールを使うことは規約違反に該当するか？ 答え：はい。 ただし正確には、LINE HARNESS 全体 ではなく、「BANされたAで得た利用者情報をBへ引き継いで配信継続する」使い方 が、公式資料上きわめて危険で、違反評価が最も自然です。 (LINE利用規約) 運用者として使うべきか？ 使うべきではありません。 理由は、公式に許可された共有の枠を超えた 利用者情報の横流し・制裁回避運用 と見なされやすいからです。特に、停止後も同じユーザー群へ同じ配信を続ける設計は、LINEの品質・ユーザー保護ロジックと正面から衝突します。 (lycbiz.com) 推奨代替案 は次の順です。 1つ目は、新アカウントで正攻法の再友だち追加 です。公式マニュアルどおり、QRコードやURLでBへ再登録を促し、Bで新たに得た情報だけで運用を始める のが最も安全です。 (lycbiz.com) 2つ目は、公式に許可された共有機能だけを使う ことです。たとえばビジネスマネージャーでの オーディエンス / LINE Tag共有 は公式機能です。ただし、これは 友だちそのものの引き継ぎ や 個別ユーザーのシナリオ進捗復元 とは別物です。 (lycbiz.com) 3つ目は、どうしてもサービス横断でユーザーデータを共通利用したいなら、Provider page / 認証済みprovider / 同一契約主体 / ユーザーへの開示 / 申請手続き という公式条件を満たし、LINEの明示的な許可の範囲内 で行うことです。これでもなお、BAN復旧のための友だち移行 を認める公式文言は今回確認できませんでした。 (LINE Developers) 最終評価 リスクレベル：★★★★★（5/5） ＿＿＿ マジで使う人の良心によるね笑はっきりいって無茶苦茶なことできてしまう。倫理的にどうかおいといてね爆笑

LINE Harness せっかく無料なのに、使い方をnoteで販売する人がいて、それ買う人がいるのであれば、そういう人はもはや代行業者に発注した方がいいと思うのは私だけですかね🤣️

Gemini CLIって本当にもったいないよね、、、モデル自体はめっちゃいいのに周辺ツールゴミすぎて話にならない。セッション途中でクラッシュしたりコンテキスト失ったりとマジできつい。複数ファイルのタスクを確実に完了できない。

なんかチャンキョメさんはマジでセキュアやなー笑できること増える分リスクも肥大化するところをしっかり理解してるからあのノートかけるし期待値調整もできる。すばらや

@ck_novasphere かったよん

@rf102_con09 もはやこれを楽しみにしてるだろharness

神のカード

@ck_novasphere 自分でやるリソースもったいないから外注して花魁に作らせたという正当化します。時間をかいますw

meta垢バン多ない？えぐいてえ

頑張るというか楽しむやな！

この人が偉大なことを成し遂げる過程を自分も追いたい…そして振り落とせないようにちょっとでも喰らいつく…最近むずすぎて学習スピード鈍化してきてるけど頑張る😤

@AI_masaou 最高っすねーー🥹感謝です🥲幸いなことに結構、両界隈がそれぞれ違う方向にベクトル向いてるのでそのまま突き進んで戻ってこないで欲しいです🥹前のnoteが解像度高すぎて化け物だったのでワクワクしてまってます🐰

@rf102_con09 今作ってるnote編集したらそこに入れようかなとは思ってます！ こんなん絶対辿り着けても自分以外見せてくれんと思うんやけどな〜笑 でも自分にもっと探索するプレッシャーかける意味で見せちゃいます😤

人類が未知に向き合うとき、道を作る指針になるのはいつも本質だった 本質とはマクロとミクロが交差する地点にある構造のこと AIエージェントでも同じで、本質を押さえて設計したハーネスとそうでないものは、見た目が似ていても中身がまったく違う 小さなハーネス用アプリを作ってみてそう実感中

やっぱビジ系でAI専門じゃない人がAIで適当な驚きで身内同士のエンゲージメントハックしてる人はどんどんインプもおちてるし、フォロワーが本心から求めてる発信をしていないのでAI疲れしてる印象。たとえばマーケの人間でめっちゃいい発信してる人やのにAIの話絡んできたら急に薄っぺらくなって萎えたり、そもそもaiわからん人に適当に横文字使った難しいポストして共感得られない。リプするほど理解してないからいいねとりあえずしとくかーで終わってる人多くなってるから気をつけないとですね。

これバカ本質

無料でケチりたいならエルメで十分やしね。痒いところには手届かないけど。たぶん詐欺プロモーションとかグレー系ジャンルでban前提の運用する案件くらいが優位性でそうな感じ。

miniでさえ買えなくなってるからどーなんすかねえええ台湾有事までには届いて欲しい

@shun_aibusiness 共同パートナーの方SEは本当に羨ましい環境です！中川さんのように僕も素晴らしい仲間見つけていけるように頑張ります！

引用ポスト読ませていただき、学ばせていただいています。 私が投稿した「マーケターがAIで恩恵を受ける」は事実。システムの要件定義・実装・検証をAIが補ってくれるから。 でもそれは「補完の恩恵」。元から全工程を自分の解像度で回せていた人にとっては「加速の恩恵」。 正直、全工程を自分の解像度で回している人の景色は、今の自分にはまだ見えていない。 だからこそ、共同代表のSEパートナーと一緒に実践しながら、研鑽が必要と感じた。

「AIで一番恩恵を受けるのはマーケター」 みたいな整理、正直かなり浅いと思う。 それって結局、AIを 「訴求作れます」「クリエイティブ作れます」「分析ちょっと楽になります」 くらいの話で見ているからそうなる。 でも本質はそこじゃない。 AIで起きているのは、 特定職種が一方的に得することではなく、 思考→要件定義→設計→実装→検証→改善 までの距離が一気に縮んだこと。 つまり、IT革命以降ずっと強かった ソフトウェア的な構造理解 と ビジネス・市場理解 を両方持っている人間が、さらに加速する局面に入ったということ。 ここを職種論で 「マーケターが得」 に落としてしまうと、本質を見失う。 実際、IT革命以降のトッププレイヤーってそうだったはず。 スティーブ・ジョブズは、ただのマーケターではない。 ハード、ソフト、UI、流通を一つの体験に束ねて事業にした。 イーロン・マスクも、ただの事業家ではない。 ソフトウェア更新、プロダクト設計、インフラ、事業構造を一体で見ている。 ホリエモンも、日本のネット黎明期から 広告・決済・メディア・インフラを“構造”で見ていた。 結局強い人って、昔から 「マーケが強い人」でも 「技術が強い人」でもなく、 市場の解像度と実装の解像度を両方持っていた人 なんだよね。 だから今起きているのも 「マーケター最強時代」ではない。 むしろ逆で、 市場全体の要求水準が上がって、 一個だけ強い人間より、 バランスよく知見を持ってAIで戦える総合力の高い人間 が勝つ競争に入ってきている。 しかも、AIは使えばいいだけじゃない。 どこまで見せるか、どこで止めるか、何を閉域で持つか、どう制御するか。 このへんまで設計できないと、速くても弱い。 だから 「AIで一番恩恵を受けるのはマーケター」 というのは、AIの表面しか見ていない人の答えだと思う。 本質はそこじゃない。 IT革命以降ずっと勝ってきた、“技術と事業を往復できる人間” が、AIでさらに加速する時代に入った という話。 なので我々はソフトウェア畑でかつ両方の知見持った人の意見をとりあえずYesマンなって自分が体で理解するまで脳死でやるがベスト。 自分がそうなってしまっているからこそ言えることだけど、AIはソフトウェアの分野なんだから変な驚き屋やエンジニア畑なだけで本質じゃない人たちに自分が意識ないまま流されて洗脳されてしまうことを常にメタ認知して常日頃から自分は間違った方向に行ってないかどうかを自問自答するのと本質見抜いてる人たちに対してアウトプットとして遠慮のないFBをもらうことだと思う。 とりあえず間違ってると思ったら、はっきりと言ってくれるまさおさんとかみたいな人がいなかったら自分は死んでたので感謝です。評価軸の質が最も重要すぎる件。

あかん色んな情報惑わされるなとか自分が言ってるのに自分が惑わされて洗脳されてた🥺冷静になるため一から見直します！まさおさんのnote何周もしてノイズのアカは物理的にミュートして遮断して注意分散しないとだ…ai疲れがやばいから1日くらいデトックスも必要だろうか？