developers · Oct 1, 2019

ヒーローになろう：Quire APIで独自アプリを作成する

✦
AI翻訳
· 英語版を見る

Quire API

最終更新：2026年5月28日

要点：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が普及する以前、パスワードを保存する連携はセキュリティ上のアンチパターンでしたが、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

Quireアプリの認証情報

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でのアプリ承認にリダイレクトする

ユーザーをQuireのOAuthエンドポイントURIにリダイレクトするための認証URLを生成します。これにより、ログイン済みの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を呼び出す

リクエストのヘッダーにアクセストークンをベアラートークンとして渡して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の重要なセキュリティ機能です。Authorization Code Grant Flowを使用する場合、アクセストークンのデフォルトの有効期間は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時間で期限切れになります。トークンを保存して更新しないアプリは、Day 1は正常に動作しますが、Day 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 APIは有料プランが必要ですか？

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

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

APIはHTTPベースでJSONのリクエスト・レスポンスボディを使用するため、HTTPクライアントとJSONパーサーを持つ言語であれば何でも使用できます。このポストのサンプルコードはJavaScriptですが、Python、Go、Ruby、PHP、その他どの言語でもまったく同じフローが機能します。公式クライアントライブラリはありません。APIサーフェスがコンパクトなため、使用言語のHTTPクライアントの薄いラッパーが一般的なパターンです。

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

アクセストークンはデフォルトで1時間後に期限切れになります。リフレッシュトークンはより長く有効で、ユーザーに再度認証を求めることなく新しいアクセストークンを取得するために使用できます。Day 1からアプリにリフレッシュトークンのループを組み込んでおきましょう。

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

はい。OAuthスコープを使用することで、アプリに必要な権限のみをリクエストできます。アプリがタスクの読み取りのみを行う場合は、読み取りスコープをリクエストしてください。Quireユーザーは認証ページでリクエストされたスコープを確認でき、過剰なリクエストと感じた場合は拒否できます。そのため、必要以上の権限をリクエストするとコンバージョン率が下がります。

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

APIは、ユーザーに代わってQuireデータを読み取ったり変更したりするあらゆるアプリ向けの汎用RESTサーフェスです。MCPサーバーはClaudeやその他のLLMエージェント専用に構築されており、認証を処理し、標準的なツールスキーマを公開するため、OAuthコードを自分で書く必要がありません。従来のアプリ連携にはAPIを、LLMエージェント連携にはMCPを使用してください。

次のステップは？

以上がQuire APIのOAuth 2.0フローのすべてです。OAuthアプリの設定、4ステップの認証、アクセストークンの使用、そしてリフレッシュループを解説しました。動作する連携を構築したものの2日後に壊れてしまう最も多い原因は、リフレッシュループを後回しにすることです。Day 1から組み込んでおきましょう。

Quireデベロッパーアプリコンソールから始めるか、完全なAPIリファレンスをご確認ください。OAuthコードを一切書きたくない場合は、Quire MCPサーバーが認証を代わりに処理してくれるため、LLMエージェント連携に最適です。イベント駆動型の連携には、多くの初回API連携が陥りがちなポーリングパターンよりも、Webhookの方が通常は適しています。

Jimmy Shiau
Software Engineer