developers · Oct 1, 2019

ヒーローになろう：Quire APIで自分だけのアプリを作る

✦
AI翻訳
· 英語版を見る

Quire OAuth 2.0 APIによるアプリ開発向けの認証フロー

最終更新日：2026年7月20日

TL;DR

Quire OAuth 2.0 APIを使うと、パスワードを保存せずに、ユーザーのQuireアカウントでアプリを動かせます。必要なのは、登録済みのOAuthアプリ（クライアントID、シークレット、リダイレクトURL）、4ステップの認可フロー（設定、リダイレクト、レスポンス処理、コードとトークンの交換）、そしてリフレッシュトークンのループです。アクセストークンは1時間で失効します。

目次

Quireのデータを読み書きするアプリを作るとき、最初に決めるのは認証の方法です。ユーザーのパスワードを一切見ずに認証するには、どうすればよいのでしょうか。Quire APIの答えは、OAuth 2.0です。この記事では、OAuthアプリの設定、4ステップの認可フロー、アクセストークンとリフレッシュのループ、そして初めての実装でよくある間違いを順に見ていきます。

QuireのOpenAPI 1.0.0は2019年10月にリリースされ、以来安定しています。OAuthを使えば、ユーザーはアプリにQuireのコンテンツ（タスク、プロジェクト、コメント、担当者、タグ、期限の日）へのアクセスを許可でき、開発者が認証情報に触れることはありません。

ユーザーはパスワードを変えずに、いつでもアクセスを取り消せます。OAuthが登場する前、パスワードを保存する連携がセキュリティ上のアンチパターンだったのは、このためです。

Quireの連携方法は、どれがあなたのケースに合いますか？

OAuth APIを組み込む前に、APIが本当に適切な手段かを確認しましょう。2026年現在、Quireには4つの連携方法があり、それぞれ解決する課題が異なります。

目的 使うもの 理由
自分のアプリで、ユーザーに代わってQuireのデータを読み書きする Quire OAuth API（この記事） ユーザー認可、フルCRUDアクセス、ポーリング不要
Quireのイベント（タスクの作成、状態の変更、コメントの追加）に反応する Quire Webhook プッシュ型でポーリングの負荷がなく、軽量に設定できる
QuireをClaudeなどのAIエージェントとつなぐ Quire MCPサーバー LLMツール向けの標準プロトコルで、構築済みのサーバーが付属
Quireを自動化やBIのワークフローに取り込む OAuth APIとn8nまたはPower BI 確立されたパイプラインで、独自コードを減らせる

モバイルアプリ、Webダッシュボード、同期サービスなど、一般的なアプリ連携を作るなら、選ぶべきはOAuth APIです。以降の内容は、この道を選んだ前提で進みます。

Quire APIのOAuthアプリは、どのように設定しますか？

Quire APIを使うには、OAuthアプリを作成する必要があります。

QuireのOAuthアプリを作成する

アプリを作成するには、Quireアカウントにログインしている必要があります。

  1. Quireの開発者向けアプリコンソールを開き、新しいアプリを作成ボタンをクリックします。 Quire開発者向けアプリコンソール

  2. アプリを所属させるQuireの組織を選びます。選択した組織のメンバーは、その組織に属するすべてのアプリを表示・編集できます。 Quireアプリの組織

  3. アプリの名前とリダイレクトURLを入力します。リダイレクトURLの役割は後ほど説明します。ここでは、次のURLを入力してください。

    http://localhost:3000/callback

  4. 新しいアプリを作成ボタンをクリックします。作成したOAuthアプリが開発者コンソールのページに表示され、さらに設定を進められます。 Quireアプリの一覧

ここまでで、次の3つの情報が手元にそろいます。

  • 開発クライアントID: :wJoMEodI4fSSR54pfNwIuIzLnaJ
  • 開発クライアントシークレット： eb8faf4nyd1wbeconw060e9ejui8zg6w8p1hyoex
  • コールバックURL: http://localhost:3000/callback

クライアントID、クライアントシークレット、コールバックURLを表示したQuire OAuthアプリの設定画面

Quire APIの開発環境は、どのように整えますか？

ステップ1. アプリを設定する

アプリの設定情報を、アプリ内に記述します。

const clientId = ':wJoMEodI4fSSR54pfNwIuIzLnaJ';
const clientSecret = 'eb8faf4nyd1wbeconw060e9ejui8zg6w8p1hyoex';
const redirectURI = 'http://localhost:3000/callback';
  
const authorizationUrl = 'https://quire.io/oauth';
const tokenUrl = 'https://quire.io/oauth/token';
const apiUrl = 'https://quire.io/api';

ステップ2. ユーザーをQuireにリダイレクトしてアプリを認可する

認可URLを生成し、ユーザーをQuireのOAuthエンドポイントURIへリダイレクトします。ログイン中のQuireユーザーが、アプリによるコンテンツへのアクセスを許可するWebページが表示されます。

URLの例：

https://quire.io/oauth?client_id=your-client-ID&redirect_uri=your-redirect-uri

認可リンクを表示するビューの例は、次のようになります。

var http = require('http');
var url = require('url');
var server = http.createServer(function (req, res) { 
    var uri = url.parse(req.url, true);
    if (uri.pathname == '/') {        
        //..    
    } else if (uri.pathname == "/install") {
        var authUrl = authorizationUrl 
            + '?client_id=' + clientId 
            + '&redirect_uri=' + encodeURIComponent(redirectURI);
        res.writeHead(200, { 'Content-Type': 'text/html' });
        res.write(
             '<html><body>' 
            + '<a href="' + authUrl + '">Connect Quire</a>' 
         + '</body></html>');
        res.end();

    } else if (uri.pathname == "/callback") {
        //...
    }
});
server.listen(3000);

stateパラメーターは、クロスサイトリクエストフォージェリ(CSRF)攻撃を防ぐためのランダムな文字列です。文字列はランダムに生成してください。この値は変更されないまま、ステップ3でアプリに返されます。アプリ側でこの値を検証してください。省略もできますが、必ず含めることを強くおすすめします。

URLの例：

https://quire.io/oauth?client_id=your-client-ID&redirect_uri=your-redirect-uri&state=lpcl9v94z

ステップ3. OAuth 2.0サーバーのレスポンスを処理する

OAuth 2.0サーバーは、redirect_uriに指定したURLを使って、アプリのアクセスリクエストに応答します。

ユーザーがアクセスリクエストを承認すると、レスポンスには認可コードが含まれます。承認しなかった場合は、エラーメッセージが含まれます。Webサーバーに返される認可コードまたはエラーメッセージは、次のようにクエリ文字列に付きます。

エラーレスポンス：

http://localhost:3000/callback?error=access_denied

認可コードのレスポンス：

http://localhost:3000/callback?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7

コールバックの例：

//...
} else if (uri.pathname == "/callback") {
   var result = uri.query;
   var message = 'Auth fail';
   if (result["error_description"] != null) {
       message = result["error_description"];
       if (result["error"] == 'access_denied') {
           //display reject message
       }
       messageView(res, message);
   } else if (result["code"] != null) {
       return exchangeAccessToken(result["code"])
       .then(function(data) {
            var token = data['access_token'];
            message = token != null ? 'Success': 'Fail';
            messageView(res, message);
        });
   }
}

ユーザーがアプリのredirect_uriにリダイレクトされるとき、クエリ文字列のパラメーターにはcodeとstateも含まれます。stateは、リクエストを検証するためのCSRF対策トークンです。

クエリ文字列のパラメーターから、codeとstateを取り出します。この時点でstateを検証できます。

検証の例：

} else if (result["code"] != null) {
    if (result["state"] != stateFromSession(res))
        return messageView(res, 'invalid state');
            
    return exchangeAccessToken(result["code"])
    .then(function(data) {
         var token = data['access_token'];
         message = token != null ? 'Success': 'Fail';
         messageView(res, message);
     });
}

ステップ4. 認可コードをアクセストークンに交換する

取り出した認可コードと、下記のリクエストパラメーターを付けて、アプリからトークンエンドポイントにPOSTリクエストを送ります。

パラメーター 値
grant_type authorization_code
code {your-authorization-code}
client_id {your-client-ID}
client_secret {your-client-secret}
redirect_uri ステップ2でredirect_uriを指定した場合は必須です。値は、そのときに使ったものと同一にしてください。

アクセストークンをリクエストする例：

var request = require('request');
function exchangeAccessToken(code) {
    return new Promise(function(resolve, reject){
        request.post({
            url: tokenUrl,
            form: {
              grant_type: 'authorization_code',
              code: code,
              client_id: clientId,
              client_secret: clientSecret,
              redirect_uri: redirectURI
            }
          },
          function (error, httpResponse, body) {
            if (error) {
              return reject(error);
            }
            resolve(JSON.parse(body))
          });
    });
}

レスポンスで受け取るアクセストークンは、JSON形式です。

レスポンスの例：

{ 
  "access_token":"ACCESS_TOKEN", 
  "token_type": "bearer", 
  "expires_in":2592000, 
  "refresh_token":"REFRESH_TOKEN"
}

トークンは、あらゆるQuire APIへのアクセスに必要です。安全な場所に、長期にわたって大切に保管してください。

Quireのアクセストークンで、APIはどのように呼び出しますか？

これで、アプリはユーザーに代わってAPIを呼び出せるアクセストークンを手に入れました。

APIを呼び出す

リクエストのヘッダーに、アクセストークンをBearerトークンとして付けて、APIを呼び出します。

API呼び出しの例：

function getCurrentUser(token) {
    return new Promise(function(resolve, reject){
        request.get({
            url: apiUrl + '/user/id/me', 
            headers: {
              "Authorization": "Bearer " + token
            }
          }, 
          function (error, httpResponse, body) {
            if (error) {
              return reject(error);
            }
            resolve(JSON.parse(body))
          });
    });
}

レスポンスの例：

{
  "email": "john@gmail.cc",
  "website": "https://coolwebsites.com",
  "id": "My_ID",
  "description": "This is *cool*!",
  "url": "https://quire.io/u/My_ID",
  "nameText": "My Name",
  "nameHtml": "My Name",
  "descriptionText": "This is cool!",
  "descriptionHtml": "This is <i>cool</i>!",
  "image": "https://quire.s3.amazonaws.com/oid/image.jpg",
  "iconColor": "37",
  "name": "My Name",
  "oid": "Dyh2YkFcu9uLgLFIeN1kB4Ld"
}

期限切れのQuire APIアクセストークンは、どのように更新しますか？

アクセストークンは、意図的に短期間の利用を前提としています。これはOAuth 2.0の重要なセキュリティ機構です。認可コードグラントフローを使う場合、アクセストークンの有効期間はデフォルトで1時間です。

アクセストークンが失効すると、HTTP 401エラーが返されます。

{ 
  code: 401, 
  message: 'Invalid or expired token.'
}

その場合、アプリ側でアクセストークンを更新する必要があります。

function refreshToken(refreshToken) {
    return new Promise(function(resolve, reject){
        request.post({
            url: tokenUrl, 
            form: {
              grant_type: 'refresh_token',
              refresh_token: refreshToken,
              client_id: clientId,
              client_secret: clientSecret
            }
          }, 
          function (error, httpResponse, body) {
            if (error) {
              return reject(error);
            }
            resolve(JSON.parse(body))
          });
    });
}

別の方法として、ユーザーを認証フローに再度リダイレクトすることもできます。

Quire APIで、開発者がよくやってしまう間違いは何ですか？

Quire APIでの開発を見てきて、同じ5つの問題が繰り返し起きています。どれも難解なものではなく、すべて避けられます。

1. クライアントシークレットをクライアント側のコードに置く。 クライアントシークレットは、その名のとおり秘密の値です。モバイルアプリのバイナリやブラウザ向けのバンドルに入っていると、誰でも取り出してアプリになりすませます。シークレットは、自分で管理するサーバーにだけ置いてください。

アプリがクライアント側だけで完結する場合（シングルページアプリやモバイルアプリ）は、シークレットを埋め込まず、OAuth 2.0のPKCEフローを使います。

2. stateパラメーターの検証を忘れる。 stateパラメーターは、CSRF攻撃を防ぐためのものです。コールバックで検証しないと、悪意のあるサイトがQuireアカウントを攻撃者のアプリのセッションにこっそり紐づけられる穴が残ります。

stateはリクエストごとに生成してセッションに保存し、返ってきたstateが一致しないコールバックは拒否してください。

3. アクセストークンを永続的なものとして扱う。 アクセストークンは1時間で失効します。トークンを保存するだけで更新しないアプリは、初日は問題なく動き、2日目に何も表示されないまま壊れます。

リフレッシュトークンのループは、リリース前に組み込んでください。「ユーザーから苦情が来たら直す」という後付けのパッチにしてはいけません。

4. 変更を知るためにAPIをポーリングする。 ポーリングは、レート制限、レイテンシ、バッテリーを無駄に消費します。Quireの変更に反応したいときは、代わりにWebhookを使ってください。

Webhookならイベントが即座に届きます。イベントを検知するために送るはずだったAPI呼び出しが、そもそも不要になります。

5. リダイレクトURLの許可リストを省く。 OAuthアプリの登録では、リダイレクトURLのリストを指定します。ワイルドカードを使ったり、正確に設定しなかったりすると、攻撃者が自分のコールバックをリダイレクト先として登録し、認可コードを横取りできてしまいます。アプリが実際に使う、正確なURLだけを追加してください。

初めてAPIで開発するなら、既存の連携を参考にするのが最短の学習方法です。たとえばn8nコネクターをフォークして、認証、リフレッシュ、エラー状態の扱い方を読み解いてみてください。

Quire APIが最適ではないのは、どんなときですか？

別の連携方法を選んだほうがよいパターンが、3つあります。

  • イベントに反応するだけで、状態を問い合わせる必要がない。 Webhookのほうがシンプルなプッシュ型で、読み取り専用のイベント購読ならユーザーの認可も不要です。アプリの役割が「何かが起きたら知らせる」ことなら、APIではなくWebhookを使いましょう。
  • ClaudeやLLMエージェントとの連携を作る。 ここではQuire MCPサーバーが最適です。認証を処理し、標準スキーマを備えているので、OAuthのコードを自分で書く必要がありません。MCPはこの用途のために作られています。OAuth APIで自作しても、手間が増えるだけで成果は同じです。
  • データを一度だけエクスポートする。 プロジェクトのデータを分析やバックアップのために一度だけ取り出すなら、n8nと連携するか、手動のCSVエクスポートを使えば、開発に1週間かけずに済みます。

どれにも当てはまらないなら、OAuth APIがあなたの選ぶべき手段です。

Quireのダッシュボード表示：プロジェクト全体をひと目で把握

よくある質問

Quire APIを使うには、有料のQuireプランが必要ですか？

いいえ。Quire APIは、フリープランを含むすべてのプランでご利用いただけます。レート制限はすべてのプランに適用されます。アプリごとの現在の上限は、APIドキュメントをご確認ください。

Quire APIはどのプログラミング言語に対応していますか？

APIはHTTPベースで、リクエストとレスポンスの本文はJSONです。そのため、HTTPクライアントとJSONパーサーがある言語なら何でも利用できます。この記事のサンプルはJavaScriptですが、同じフローがPython、Go、Ruby、PHPなど、他の言語でも同じように使えます。

公式のクライアントライブラリはありません。APIの範囲がコンパクトなので、使う言語のHTTPクライアントを薄くラップするのが一般的な方法です。

Quireのアクセストークンは、どのくらいの期間有効ですか？

アクセストークンの有効期間は、デフォルトで1時間です。リフレッシュトークンはそれより長く有効で、ユーザーに再度確認することなく、新しいアクセストークンを取得できます。リフレッシュトークンのループは、初日からアプリに組み込んでください。

Quire APIを読み取り専用で使えますか？

はい。OAuthスコープを使えば、アプリに必要な権限だけをリクエストできます。アプリがタスクを読み取るだけなら、読み取りスコープをリクエストしてください。Quireのユーザーには、認可ページでリクエストされたスコープが表示され、過剰だと感じれば拒否できます。そのため、必要以上に要求すると、認可の完了率が下がります。

Quire APIとQuire MCPサーバーの違いは何ですか？

APIは汎用のRESTインターフェースで、ユーザーに代わってQuireのデータを読み書きしたいあらゆるアプリに使えます。MCPサーバーはClaudeなどのLLMエージェント向けに作られており、認証を処理し、標準のツールスキーマを公開します。そのため、OAuthのコードを自分で書く必要はありません。

従来型のアプリ連携にはAPIを、LLMエージェントとの連携にはMCPをお使いください。

ここから、どこへ進めばよいですか？

以上が、Quire APIのOAuth 2.0フローの全体像です。OAuthアプリの設定、4ステップの認可、アクセストークンの使い方、そしてリフレッシュのループを解説しました。

動いていたはずの連携が2日後に壊れる最大の原因は、リフレッシュのループを後から直せばよいものとして扱い、初日から組み込まなかったことです。

まずは、Quireの開発者向けアプリコンソールを開くか、APIリファレンスをご覧ください。OAuthのコードをまったく書きたくない場合は、Quire MCPサーバーが認証を処理します。LLMエージェントとの連携には、こちらが最適です。

イベント駆動の連携には、初めてのAPI連携が行き着きがちなポーリングよりも、Webhookのほうが適していることが多いです。また、OAuthアプリを作らずに手早く変更をスクリプト化したい場合は、QuireのCLIを使えば、ターミナルから直接プロジェクト管理のコマンドを実行できます。

Jimmy Shiau
Software Engineer