既存WebをLIFF化するのは簡単なのか？認証があったら簡単じゃないのか？を試してみた

既存のWebサービスをLINEミニアプリ化したいという相談に対して「技術的に成立するか」を自分の手で検証しました。LIFFの追加作業がどこまで「おまじない」で済むのか、認証はどう扱うべきか、3つの実験を通じて見えてきたことをお伝えします。
2026.05.26
こんにちは。リテールアプリ共創部の事業企画を担当しているかめだです。
「既存のWebサービスをそのままLINEミニアプリ化できないか」という相談を受けたことがあります。ネイティブアプリやゼロから構築するECサイトへの投資は避けたい、でもLINEという接点でユーザーとつながりたい、という判断です。ごく自然な要求だと思います。
「LIFFというものを使えば既存WebをLINEで開ける」という話は知っていましたが、既存Webが持つ「ログイン済みの状態」をどう扱うのかが提案資料を書く前から気になっていました。「LIFF化＝ヘッダーにおまじないを一行入れるだけ、で本当に済むのか」という疑問です。
提案資料を書く前に、これを自分の手で確かめることにしてみました。
 1. 私が確かめたかった3つの問い想定している相談のパターンはこうです。「ECサイトを持っているが、LINEでも同じ体験を提供したい。ゼロからLINEミニアプリを作るのではなく、今あるWebをベースにできないか」というものです。
開発コストを抑えたい、リリースを早めたい、既存のユーザーデータベースを活かしたい。これらは合理的な要求です。
では、何が難しいのか。私が確かめたかったのは、以下の3点です。
既存のWebページに LIFF SDK（LIFFの機能を呼び出すためのJavaScriptライブラリ）を埋め込むだけで、LINEのユーザー情報は取れるのか
既存WebがCognitoなどで「ログイン機能」を持っている場合、LINEミニアプリの中からそのログイン画面を呼び出せるのか
LINEミニアプリから外部の認証ページに飛ばして認証を完了させ、LINEミニアプリへ戻ってきたとき、ログイン状態はキープされているのか。LINEミニアプリ用に「ログイン画面」「新規登録画面」を新しく作らずに済むか
3つ目が、いちばん重要な問いです。「LINEミニアプリ専用のログインフォームや新規登録画面を別途作らなければならないのか」という問いに答えられないと、開発スコープの見積もり自体が変わります。既存Webが持つ認証の画面をそのまま流用できるかどうかは、案件の工数と直結します。
 2. WebをLIFF化するとは、どういう構造になるのかまず、言葉の整理から始めます。
LIFFとは何か
LIFF（LINE Front-end Framework）は、LINEのトーク画面などからWebページをLINEアプリの画面内で開くための仕組みです。LINEミニアプリを「ゼロから作った専用アプリ」だとすると、LIFFは「既存のWebページをLINEの画面の中で開けるようにしたもの」に近いイメージです。
LIFF SDKは、そのLIFFの機能をWebページの中から呼び出すためのJavaScriptライブラリです。「LINEユーザーIDを取得する」「LINE公式アカウントにメッセージを送る」といった機能を、数行のコードで使えるようにしてくれます。
LIFF化の全体像
「既存WebをLIFF化する」とは、技術的には、既存の画面をLIFF SDK + LINE Loginの薄い層が外側からくるんでいるだけで、画面の中身（HTMLとJavaScript）や、画面が接続しているサーバー・データベースはそのまま、という形になります。
緑の外側の枠が新規に追加するLIFF SDK層で、グレーの内側が既存資産をそのまま使う部分です。この図を見ると「既存Webをくるむだけで済む」という期待は確かに成立しているように見えます。
ところが、この図には書かれていない大事な論点があります。既存Webがログイン機能を持っている場合、そのログイン処理はLINEアプリの中のブラウザ（以下「LINEブラウザ」と呼びます）でも動くのか。既存のログイン画面・新規登録画面・パスワードリセット画面をそのまま流用できるのか。これらが成立しなければ、上の図は絵に描いた餅です。
今回の3実験は、この図が現実に成立するかどうかを分解して確認するものです。
LIFF SDKを既存HTMLに埋め込めば、LINEのユーザー情報は取れるのか（実験1）
既存WebがCognito等のログイン機能を持っている場合、LINEミニアプリの中からその認証フローを呼び出せるのか（実験2）
認証UIをLINEミニアプリの外（既存Webの認証ページ等）に外出ししても、LINEミニアプリへ戻ったときログイン状態になるのか（実験3）
 3. 自分の手で構築した記録 Step 1: LIFFアプリを登録する確認したかった点: LIFFアプリの登録に必要な情報と、URLの設定ルールを把握する。制約を知らずに提案すると「実は使えなかった」が後から出る。
LINE Developers Consoleページで、チャネルを作成してLIFFアプリを追加します。設定項目で重要なのがエンドポイントURL（LIFFアプリの本体となるHTMLが置いてある場所のURL）の登録です。
設定のポイントは3つです。
エンドポイントURLはHTTPSが必須です。http:// で始まるURLや、開発用の自己署名証明書では使えません
登録したURLとその配下のパスでのみLIFFが動作します。「/liff/ 以下を登録したのに、同じサーバーの /auth/ で呼ぼうとした」のような使い方はできません
LIFFアプリのサイズ（Full / Tall / Compact）は、全画面表示するならFullを選びます
ハマり1: LIFF用URLとエンドポイントURLを混同すると「LINEで開いたのに動かない」が発生する
LINEアプリの中でページを開くためのURLは LIFF URL（https://liff.line.me/〈数字とハイフンの文字列〉）です。このURLをLINEのトークなどからタップすると、LINEブラウザでLIFFアプリが起動します。
一方、エンドポイントURLは自分のサーバーのHTMLが置いてある場所のURLです（例: https://experiment-1/）。こちらを直接ブラウザで開いても、いつも使っているSafariやChromeで普通のWebページとして開かれるだけです。
最初の検証で「LINEで開いたはずなのに、LINEアプリの中で開いているか判別する関数が『外部ブラウザで開いています』と返してくる」という事象を引きました。原因は、メッセージで送ったURLがLIFF URLではなくエンドポイントURLだったことでした。LINE経由でLIFFを開きたいときは、必ず https://liff.line.me/〈LIFF ID〉 の形式のURLを使います。
なお、iOSのLINEアプリの設定で「リンクを外部ブラウザで開く」をオンにしていると、LIFF URLから開いてもSafariに飛ばされてしまいます。検証時にはLINEの設定も確認しておく必要があります。
業務上の影響: これに気づかないまま「LINE上でちゃんと開いているのに動かない」と詰まると、環境構築で半日以上止まります。デモや社内検証の場で「一旦動かして見せる」ためには、まずこの2つのURLの違いを理解しておくことが前提になります。
登録が完了するとLIFF IDが発行されます。2006xxxxxxxxx-xxxxxxxx のような形式の文字列で、実装コードの中で使います。
この Step でわかったこと: LIFFアプリの登録自体は数分の作業です。LINE Developers Consoleのアカウントさえあれば、本格的な開発に入る前でも、URLを払い出してコードを書く準備は1日以内に整います。「まずデモを動かして見せてから提案したい」という進め方も、この段階から始められます。
 Step 2: 既存のHTMLにLIFF SDKを埋め込む（実験1）確認したかった点: 既存のHTMLページにSDKを数行追加するだけでLINEのユーザーIDが取れるのか。「おまじない1行」という理解が正しいかを確かめる。
実装は最小限のHTMLです。<head> タグの中にSDKを読み込む1行を追加し、JavaScriptで「LIFFを起動して、ユーザー情報を取得する」処理を書くだけです。
以下のコードは、LIFFを初期化してユーザー情報を画面に表示するための最小実装です。LINEアプリ経由で開くと、ボタンを押すことでLINEのユーザーIDと表示名を取得できます。
<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <!-- LIFF SDKの読み込み（この1行でLIFFの機能が使えるようになる） -->
  <script src="https://static.line-scdn.net/liff/edge/2/sdk.js"></script>
</head>
<body>
<pre id="profile">未取得</pre>
<button id="login">ログイン / プロフィール取得</button>

<script>
const LIFF_ID = "2006xxxxxxxxx-xxxxxxxx"; // 発行されたLIFF ID

(async () => {
  // LIFFを初期化する（この処理が終わるまで後続の処理は待機）
  await liff.init({ liffId: LIFF_ID });

  // 既にログイン済みなら、すぐにプロフィールを取得して表示
  if (liff.isLoggedIn()) {
    const profile = await liff.getProfile();
    document.getElementById("profile").textContent
      = JSON.stringify(profile, null, 2);
  }

  // ボタンを押したときの処理
  document.getElementById("login").addEventListener("click", () => {
    // 未ログインならLINEのログイン画面へ飛ばす
    if (!liff.isLoggedIn()) { liff.login(); return; }
    // ログイン済みならプロフィールを取得して表示
    liff.getProfile().then(p =>
      document.getElementById("profile").textContent = JSON.stringify(p, null, 2)
    );
  });
})();
</script>
</body>
</html>
公式ドキュメントによれば、liff.init() が成功した後に liff.getProfile() を呼ぶことで、LINEのユーザーID・表示名・プロフィール画像URLを取得できます。また liff.getIDToken() で、バックエンドが「このユーザーは確かに認証されました」と確認するための証明書のような文字列（IDトークン）が得られます。
この実験でわかったのは「LINEユーザーIDを取るだけなら、既存Webに最小限の手を入れれば成立する」ということです。ただし、これは「まだログインしていないユーザーがログインボタンを押す」という操作を前提にしています。「既存ユーザーがいつの間にかLINE認証に切り替わっていた」という体験にするためには、追加の設計が必要です。
この Step でわかったこと: 認証なしの単純なページ（商品カタログ、店舗案内、LP など）をLINEミニアプリ化したいだけであれば、LIFFの追加作業は比較的軽微です。既存Webのエンジニアに「このページにLIFFを追加してほしい」と頼めばすぐ対応できるレベル感です。ただし「ログインが必要なページ」が含まれた瞬間、話が変わります。それが次の実験です。
 Step 3: Cognitoのログイン画面を用意する確認したかった点: 既存WebがCognitoでログイン管理している場合、LIFFから接続するための土台を作る。
Amazon Cognitoは、「ユーザーの登録・ログイン・パスワードリセットを一括で管理してくれるAWSのサービス」です。ログイン画面（ログインフォーム、パスワード入力欄）を自分でHTMLから作らなくても、Cognitoが用意してくれる既製のログイン画面（Hosted UI）をそのまま使えます。
「認証は別のサービスに任せて、その結果を受け取る」という仕組み（OAuth 2.0）で動いており、ユーザーがCognitoのログイン画面でID/パスワードを入力すると、認証完了後に指定したURL（redirect_uri、リダイレクトURIと読む）に自動でブラウザが戻ってきます。
設定で意識すべき点は2つです。
redirect_uri（認証後に戻す先のURL）: Cognito側に事前登録しておく必要があります。今回の実験では、LIFFのエンドポイントURL配下に callback.html というページを置き、そこを登録しました。事前登録と実際のURLが1文字でも違うとエラーになります
Authorization code grant（認証の方式）: Cognitoが発行する「認証コード」をいったん受け取り、それを「IDトークン（認証済み証明書のような文字列）」に交換する方式です。古い「Implicit grant」という方式はセキュリティ上の問題があり、現在は非推奨とされています
この Step でわかったこと: Cognitoの設定は、AWSマネジメントコンソールのGUI操作で完結します。既存Webが既にCognitoを使っているなら、設定変更と callback.html の追加だけで連携の土台が作れます。全くの新規構築でも、Hosted UIという既製のログイン画面が使えるため、「ログインフォームのデザインと実装」という工程をスキップできます。
 Step 4: LINEミニアプリの中からCognitoのログイン画面を開く（実験2）確認したかった点: LINEブラウザからCognitoのログイン画面に移動し、ログイン完了後にLINEミニアプリへ戻ってこられるか。
実験2では、「LINEブラウザの中で同じタブのままCognitoへ移動する経路（A案）」と「LINEとは別のブラウザ（SafariやChromeなど）でCognitoを開く経路（B案）」の2パターンを試しました。
以下のコードは、CognitoのログインページURLを作成して、2つの経路で開く実装です。
// Cognitoのログインページへ移動するためのURLを組み立てる
function buildAuthorizeUrl() {
  // 「なりすまし防止コード」として乱数を生成し、ブラウザのメモ帳（sessionStorage）に保存しておく
  const state = crypto.randomUUID();
  sessionStorage.setItem("oauth_state", state);

  // CognitoのログインページへのURLを組み立てる
  const u = new URL(`https://${COGNITO_DOMAIN}/oauth2/authorize`);
  u.searchParams.set("response_type", "code");   // 認証方式: コード交換方式
  u.searchParams.set("client_id", CLIENT_ID);     // このサービスのID
  u.searchParams.set("redirect_uri", REDIRECT_URI); // ログイン後に戻るURL
  u.searchParams.set("scope", "openid email");    // 取得したい情報の範囲
  u.searchParams.set("state", state);             // なりすまし防止コード
  return u.toString();
}

// A案: LINEブラウザの中でそのままCognitoへ移動する
document.getElementById("login-inside").addEventListener("click", () => {
  location.href = buildAuthorizeUrl(); // 今のタブでそのまま移動
});

// B案: SafariなどのLINE以外のブラウザでCognitoを開く
document.getElementById("login-external").addEventListener("click", () => {
  liff.openWindow({ url: buildAuthorizeUrl(), external: true }); // 外部ブラウザで開く
});
ログインが完了すると、Cognitoが指定した callback.html（認証が終わった後に自動で戻されるWebページ）にブラウザを転送します。callback.html では受け取った「認証コード」をCognitoに送って「IDトークン（認証済み証明書）」と交換し、ブラウザのメモ帳（sessionStorage、ブラウザが一時的に値を覚えておける領域）に保存した後、元のLINEミニアプリのページへ戻ります。
この一連の流れを図にすると次のとおりです。
以下のコードが callback.html での「認証コード → IDトークン交換」の処理です。
// URLのパラメータから認証コードとなりすまし防止コードを取り出す
const params = new URLSearchParams(location.search);
const code = params.get("code");

// 認証コードをIDトークンに交換するリクエストを送る
const body = new URLSearchParams({
  grant_type: "authorization_code",
  client_id: CLIENT_ID,
  code,
  redirect_uri: REDIRECT_URI,
});
const res = await fetch(`https://${COGNITO_DOMAIN}/oauth2/token`, {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body,
});
const json = await res.json();
if (json.id_token) {
  // IDトークン（認証済み証明書）をブラウザのメモ帳に保存
  sessionStorage.setItem("cognito_id_token", json.id_token);
  // 元のLINEミニアプリのページへ戻る
  location.href = "./index.html";
}
ハマり2: callback.html の中のCognitoドメインやクライアントIDを書き換え忘れると、Cognitoのログイン画面までは動くのに「戻り」で止まる
検証コードは、最初は REPLACE.auth.ap-northeast-1.amazoncognito.com のような仮の文字列で書いていました。Cognitoの設定が終わって実際の値に置き換えるとき、index.html の置き換えは済んでいたのに callback.html の置き換えが漏れていました。結果として、Cognitoのログイン画面まではちゃんと開いて、ログインもできて、callback URLにもリダイレクトされてきたのに、そこから先の「IDトークンの取得」処理が Failed to fetch で止まるという事象になりました。URLに ?code=xxx&state=yyy が付いて戻ってきていればCognito側は正常に終わっているので、複数のHTMLファイルで同じCognito情報を使っている場合は、全ファイルの置き換えが完了しているかを確認します。
業務上の影響: LINEミニアプリの検証環境を別の人に引き渡すとき、定数の置き換えが必要なファイルのリストを一覧化しておかないと、受け取った側が「動かない→原因不明」で時間を溶かします。デモ環境のセットアップ手順書には、このレベルの粒度で書いておくことを勧めます。
実験2で、LINEブラウザの中にログイン結果を持ち込める経路はA案（同タブでそのまま移動）です。認証の流れがLINEブラウザの文脈の中で完結するため、callbackからブラウザのメモ帳（sessionStorage）経由でIDトークンを引き渡せます。一方、B案（外部ブラウザで開く）は、ログイン自体は成功しても、外部ブラウザとLINEブラウザは互いに相手の記憶域を読めないため、ログイン結果がLINEミニアプリ側に届きません（この仕組みは実験3で詳しく確認します）。
この Step でわかったこと: 「LINEブラウザの中でそのままCognitoへ移動して戻ってくる」という経路は、設定と定数の置き換えが正しければ成立します。既存Webが既にCognitoを使っているなら、認証フロー自体を作り直す必要はなく「LIFF用のCallback URLを追加登録する」作業だけで連携の土台が整います。ただし次の実験3で確認するとおり、「外部ブラウザ経由ではなく、LINEブラウザの中での同タブ移動に限る」という制約があります。
 Step 5: 認証画面をLINEミニアプリの外に置いても大丈夫か（実験3）確認したかった点: LINEミニアプリから外部の認証ページに飛ばして認証を完了させ、LINEミニアプリへ戻ってきたとき、ログイン状態として動作するか。これが成立すれば、LINEミニアプリ用にログイン・新規登録・パスワードリセット画面を新しく開発する必要はない。
この論点は開発スコープに直結します。既存Webのログインページをそのまま使えるなら、「LINEミニアプリ専用のログイン画面をゼロから作る」という工程がなくなります。逆に使えないなら、既存のログイン画面とは別にLINEミニアプリ専用の画面が必要になり、工数が増えます。
実験3では2つの経路を「ログイン画面をLINEミニアプリの外に置けるか」という視点で確認しました。
A案: LINEブラウザの中でそのまま移動する（本命）
実験2のA案と同じ構造です。location.href でCognitoのログイン画面に同タブのまま移動し、ログイン後に callback.html を経由してLINEミニアプリへ戻ります。ログインの流れがLINEブラウザの中で完結するため、callbackからLINEミニアプリへ戻ったときにIDトークン（ログイン済みの証明）をブラウザのメモ帳経由で引き渡せます。つまり、LINEミニアプリ用にログインフォームを新規開発しなくても、既存のCognitoログイン画面（Hosted UI）をそのまま流用できます。
B案: 外部ブラウザ（Safari/Chromeなど）で認証ページを開く（不採用）
liff.openWindow({ url: cognitoUrl, external: true }) でSafariやChromeなど「いつも使っているブラウザ」にCognitoのログイン画面を開き、ログイン後にLINEアプリに戻る経路です。
ここで重要な構造的な事実があります。LINEブラウザは、いつも使っているSafari/Chromeとは別の「記憶域」を持っており、お互いに参照できません。
Webブラウザは、ログイン状態などを「Cookie（クッキー）」や「localStorage（ローカルストレージ）」と呼ばれる記憶域に保存します。Safari で何かにログインした情報は、LINE の中のブラウザからは見えません。逆も同様です。まったく別の引き出しだと考えると分かりやすいと思います。
以下のコードは実験3のLINEミニアプリ側で、外部ブラウザでログインした後に記憶域が共有されているかを確認するものです。
// localStorage（ブラウザのメモ帳・長期保存版）の確認
const ls = localStorage.getItem("cognito_id_token");
// → ❌ 外部ブラウザでログインしても、LINEブラウザからは見えない

// Cookie（ブラウザが保存するセッション情報）の確認
const ck = document.cookie.split(";").map(s => s.trim())
  .find(s => s.startsWith("cognito_id_token="));
// → ❌ こちらも同様に見えない
ハマり3: 外部ブラウザ経由で認証しても、LINEミニアプリ側はログイン状態にならない
B案の経路は、外部ブラウザでログイン自体は通っています。ただし、その「ログイン済み」の情報はLINEブラウザの記憶域には届きません。LINEブラウザと外部ブラウザは完全に別々の記憶域を持っているためです。URLパラメータ（URLの末尾に ?token=xxx のような形で情報を付加する方法）でIDトークンを渡す方法も考えられますが、URLが流出するとログイン情報が漏れるため本番環境では使えません。
業務上の影響: 「とりあえず Safari で先にログインしておいて、LINE から開いたときにはもうログイン済みにしておく」という設計は成立しません。提案の場で「既存のログインをそのまま使えます」と言えるかどうかは、「どの経路でログインさせるか」によって変わります。この前提を握らずに提案すると、開発フェーズで仕様変更が出ます。
この実験でわかったのは「LINEミニアプリ用にログイン・新規登録画面を新しく作らないことは可能だが、ログインページへの移動経路は『LINEブラウザの中でそのまま移動する』に限定される」ということです。既存Webの認証ページをそのまま流用したい場合も、そのページをLINEブラウザの中でフルページ遷移できる経路で呼び出す設計にしておく必要があります。
この Step でわかったこと: 「LINEミニアプリ専用のログイン画面を作り直さなくていい」は成立します。ただし条件があります。ログインページへの移動は必ずLINEブラウザの中での同タブ移動にすること、です。既存WebのログインページやCognitoのHosted UIを流用する場合も、この経路で呼び出せる構造になっているかを事前に確認します。
 4. 動かして見えてきた手応えと壁 実験1の手応えLIFF SDKの埋め込み自体は、想定どおりシンプルでした。既存のHTMLに <script> タグ1行とJavaScriptを数十行足すだけで、LINEのユーザーIDとプロフィールを取得できる設計になっています。HTTPS必須という制約はありますが、開発環境にVercelプレビューを使う習慣があれば特別な障壁にはなりません。
商品カタログ・店舗案内・キャンペーンLPなど、認証を必要としないページをLINEミニアプリ化したいだけなら、この実験の範囲で話は終わります。「最小工数でLINE導線を確保したい」という案件には、今回の構成がそのまま使えます。
 実験2と3で見えてきた壁壁の本質は「LINEブラウザが、通常のSafariやChromeとは完全に分離した記憶域を持っている」という点に集約されます。
LINEブラウザと外部ブラウザはCookie・localStorage等の記憶域が別々のため、外部ブラウザで完了したログインセッションはLINEミニアプリ側に自動では届きません
ログイン画面をLINEミニアプリの外に外出ししても、LINEミニアプリへ戻ったときにログイン状態として動作させるには、LINEブラウザの中での同タブ移動経路に限られます
LIFF→外部ブラウザ→LINE復帰のルートでログインを完結させたい場合は、バックエンドを介したID紐付けなど追加の仕組みが必要になります
これらの壁は「技術的に突破できない」ものではありませんが、突破するためにはアーキテクチャの変更が必要で、「既存Webをそのまま流用できる」という期待とのギャップが生じます。
 まとめ冒頭で立てた仮説は「LIFF化＝既存Webのヘッダーにおまじないを一行入れるだけで済むのか」でした。これを分解した3つの問いに対して、実機で検証した結論は次のとおりです。
 問い1: 既存のWebページにLIFF SDKを埋め込むだけで、LINEのユーザー情報は取れるのか答え: 取れる。仮説どおり「おまじない」レベルで成立する。
<script> タグ1行と数十行のJavaScriptだけで、LINEのユーザーID・表示名・プロフィール画像URLが取得できました。既存HTMLに最小限の手を入れるだけで、LINEのユーザーIDを既存ロジックに引き渡せます。
→ つまり、認証なしの商品カタログ・店舗案内・コンテンツページをLINEミニアプリ化したいだけなら、最小工数で対応できます。提案の場で「まず非ログインページから始めましょう」という段階的な進め方がしやすくなります。
 問い2: 既存WebがCognitoなどのログイン機能を持っている場合、LINEミニアプリの中からそのログイン画面を呼び出せるのか答え: 呼び出せる。ただし「LINEブラウザの中でそのまま移動する」経路に限られる。
LINEミニアプリから同タブのままCognitoのログイン画面へ移動し、ログイン完了後にcallback経由でLINEミニアプリへ戻る経路は成立しました。SafariなどのLINE以外のブラウザでCognitoを開く経路は、ログイン自体は通っても結果がLINEミニアプリへ届きません。
→ つまり、既存WebがCognitoを使っているなら、ログインフロー自体を作り直す必要はありません。「Callback URLを追加登録する」だけで連携の土台が整います。ただし「外部ブラウザに飛ばす経路は使えない」という制約は、提案時に明示しておく必要があります。
 問い3: 認証画面をLINEミニアプリの外に置いても、LINEミニアプリへ戻ったときログイン状態はキープされているのか答え: 自動ではキープされない。「Safariで先にログイン → LINEから開いたら既ログイン」というシナリオは成立しない。
LINEブラウザと外部ブラウザは互いの記憶域を参照できないため、Safariで先にCognitoログインを済ませておいてもその情報はLINEミニアプリ側に届きません。「ユーザーがブラウザで事前に登録・ログインしておけば、LINEから開いたときはもうログイン済み」という自動的な体験は、現構造では作れません。
ただし、これは「LINEミニアプリ用に認証画面を作り直す必要があるか」とは別の話です。LINEミニアプリから同タブでログインページに移動して戻る経路（問い2の答えと同じ構造）を取れば、LINEミニアプリ用に新しいログイン・新規登録画面を作らなくても、既存Webの認証ページをそのまま流用できます。
→ つまり、「LINEミニアプリ専用のログイン画面は不要」は成立します。ただし「ログイン画面はLINEブラウザの中での同タブ移動で呼び出せる構造にしておく」という条件は、設計の初期段階で握っておく必要があります。これを後から変えると、フロントエンドの設計に影響が出ます。
 全体の結論仮説「LIFF化＝ヘッダーにおまじない」は、ログインが不要な静的Webに限れば成立します。ログインが絡んだ瞬間、ヘッダー1行では済まなくなります。ただし設計の方針さえ正しく握れば、既存のログイン画面・認証フローをほぼそのまま使いながらLINEミニアプリ化できます。「全部作り直し」ではなく「経路の設計だけ調整する」イメージです。
「既存WebをそのままLINEミニアプリ化したい」という相談に対して、技術的に成立するか・しないかの一次返答を、自分の手で動かした検証結果に基づいて返せるようになりました。
同じテーマで「既存Webを活かしてLINEミニアプリ化したいが、認証まわりの設計をどう握ればよいか」を検討している方は、設計の方針を一緒に整理できます。
既存WebのLINEミニアプリ化などの相談先をお探しの方は、グロースパック for LINEのページからご連絡ください。
グロースパック for LINE — LINEミニアプリ・LIFF活用支援